Re: Innovation in Debian
On Mon, Jul 22, 2013 at 04:39:54PM +0100, Michael Tautschnig wrote: [...] I feel the subject of this thread is not very well aligned with your reasoning - I don't think innovation==breaking things!? At least for myself the init system I very much disagree. Without deviation from the norm, progress is not possible Alas, most of the time, with software, deviation means incompatibilities. Not everything can be transitioned gracefully. Absolutely so in the early days of work, which is when we need this most of all. As a result, people refuse to embrace progress for fear of breaking things, or not being able to back the change out. Re-read some of the recent threads. is a particularly bad example: I have quite a while ago stopped following that thread as the noise/information ratio was way too high for a sub-system I don't necessarily care about (I just need *some* working init). To re-iterate: are you worrying about innovation or about a lack of interest in breaking things? I don't think there's a lack of interest in innovating. I just don't think we have a way to do it without putting thumb-screws on excited people, and weighing them down. Personally, with desktop-base, I want to split the package to allow for more correct dependencies. I want to try this split out, and see how it works on a real system. Here's the process: - Get a server - Set up dak (ok, really reprepro would be fine, but I'm making a point) - Set up wanna-build - Get some build boxen - Upload new desktop-base with changes - NMU packages in the archive to work with the new packages in the overlay - Fiddle with it - Push work back to Debian main This is stupid. I don't want to screw with servers to try out some ideas. I want the process to be something like: - New PPAMAIN - Upload new package - NMU packages to work with the new stuff (this needs to be something that the project is OK with) inside the PPA - Fiddle - Push it back up Screwing with setting up servers is absurd. I just want to hack. I don't want to maintain the archive. I don't want to maintain the servers. I don't want to support build boxen. We need to find a way to get the boring stuff out of the way for people excited about change, and not try to box them into non-breaking changes only while they work out the kinks. Best, Michael Yes, this is about breaking things. We can't restrict innovation to non-breaking changes. By letting DDs break things in a little corner, there's a good chance that this helps come up with a *real* transition plan that prevents breakage on real machines. Either way, semantics, IMHO, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Innovation in Debian
On Mon, Jul 22, 2013 at 04:39:54PM +0100, Michael Tautschnig wrote: [...] I feel the subject of this thread is not very well aligned with your reasoning - I don't think innovation==breaking things!? At least for myself the init system I very much disagree. Without deviation from the norm, progress is not possible Alas, most of the time, with software, deviation means incompatibilities. Not everything can be transitioned gracefully. Absolutely so in the early days of work, which is when we need this most of all. I do see that some innovative ideas cause breakage. And sometimes breaking things may result in progress. All I was saying is that innovation and breaking things are not the same. In an ideal world, people would come up with innovative ideas, think them through, and then come up with a plan that breaks as little as possible. (No, we don't live in an ideal world.) As a result, people refuse to embrace progress for fear of breaking things, or not being able to back the change out. Re-read some of the recent threads. I get your point. is a particularly bad example: I have quite a while ago stopped following that thread as the noise/information ratio was way too high for a sub-system I don't necessarily care about (I just need *some* working init). To re-iterate: are you worrying about innovation or about a lack of interest in breaking things? I don't think there's a lack of interest in innovating. I just don't think we have a way to do it without putting thumb-screws on excited people, and weighing them down. I tend to disagree, but I don't have any hard facts to back up my claim. Therefore I'll go with your example: Personally, with desktop-base, I want to split the package to allow for more correct dependencies. I want to try this split out, and see how it works on a real system. Here's the process: - Get a server - Set up dak (ok, really reprepro would be fine, but I'm making a point) - Set up wanna-build - Get some build boxen - Upload new desktop-base with changes - NMU packages in the archive to work with the new packages in the overlay - Fiddle with it - Push work back to Debian main This is stupid. I don't want to screw with servers to try out some ideas. I want the process to be something like: - New PPAMAIN - Upload new package - NMU packages to work with the new stuff (this needs to be something that the project is OK with) inside the PPA - Fiddle - Push it back up Screwing with setting up servers is absurd. I just want to hack. I don't want to maintain the archive. I don't want to maintain the servers. I don't want to support build boxen. May I dare to say you are lacking innovation here? Look at what Mika did in his kantan project (http://grml.org/kantan/). No, he did not stick his head in the sand when working towards testing grml. But actually all you need is a virtual machine. Or maybe not even that: just use http://collab-maint.alioth.debian.org/debtree/ which won't even require a single package build. Just look at (or automatically analyze) the output. We need to find a way to get the boring stuff out of the way for people excited about change, and not try to box them into non-breaking changes only while they work out the kinks. [...] I fully agree with this point, but at the same time I'd hope that people go the might-break-things route only once they thought about it. Breaking things out of plain laziness is not acceptable. Yes, this is about breaking things. We can't restrict innovation to non-breaking changes. By letting DDs break things in a little corner, there's a good chance that this helps come up with a *real* transition plan that prevents breakage on real machines. Either way, semantics, IMHO, Paul When (potentially) breaking things is the only way to achieve progress in a particular sub-project then this shall be ok. (Obviously a comment I should be making in other threads and likely there will be people who disagree.) But *please* don't push for a routine of breaking things as a general means towards progress. As I tried to show for your example above: there may be other solutions to a problem, and these may even be more efficient. This isn't anyone's personal sand-pit, so please be considerate of both users of fellow DDs by putting in a reasonable amount of effort to think about safer solutions. Best, Michael pgpdL18Apujnz.pgp Description: PGP signature
Re: Innovation in Debian
Ahoy, I am not active in Debian development much but I do observe it closely and must say that Debian needs innovation a lot - not for purpose to innovate but there are so much talented people with great ideas that just need to *explode*. For me, unstable or experimental should be *just do it* and develop it so Debian gains momentum (or some other nice solution to gain that). DD's should encourage among themselves this kind thing and to pass it on others in Debian project (contributors of any kind - code developers, translators, artist etc.). It would be good to quickly create some base (innovation is quick) like some website with database so everyone could be pointed at and to announce it on Bits, News and every Linux related website/blog such as Distrowatch, Phoronix (we may or may not like those but they have fair audience), LWN, Linux Foundation etc. Btw, maybe we should call/encourage some (for now) non-Debian developers to attend DebConf and Debian IRC channels more frequently? I know we are welcoming but we **suck** at exposing our project to worldwide community because its really hard for average developer to even find about Debian Project on itself (or am I mistaking :p ). Cheers, zlatan On Mon, Jul 22, 2013 at 2:54 PM, Paul Tagliamonte paul...@debian.orgwrote: Ahoy, fellow developers, Having followed the recent threads, I've been growing concerned - not of sticking with an old init system, or switching to a new one, or even the god-aweful tone of every damn post on that thread (srsly guise). I'm mostly concerned that we, as a project, have a *hard* time trying out big, breakey things -- I know, we're Debian, we're stable, I get that. So, given that no one wants to upload something broken to unstable (lots of users, might end up in stable and have to support it for 5 years), how can we, as a project, step up innovation in Debian? Where can we break these things and try out new bits of integration? I certenly don't have time to manage setting up infra to manage a fork (or even a private overlay) of Debian, so how can we support these new bits inside Debian? We do have PPAs coming up - we could use those with breaking NMUs (PPA Owner Uploads? POU?) of packages to help with integration, but I fear there might be project backlash over that. So, what do *you* think? How can we break more of Debian for fun and profit? Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag -- Its not the COST, its the VALUE!
Re: Innovation in Debian
Hi Paul, hi all, Ahoy, fellow developers, Having followed the recent threads, I've been growing concerned - not of sticking with an old init system, or switching to a new one, or even the god-aweful tone of every damn post on that thread (srsly guise). I'm mostly concerned that we, as a project, have a *hard* time trying out big, breakey things -- I know, we're Debian, we're stable, I get that. [...] I feel the subject of this thread is not very well aligned with your reasoning - I don't think innovation==breaking things!? At least for myself the init system is a particularly bad example: I have quite a while ago stopped following that thread as the noise/information ratio was way too high for a sub-system I don't necessarily care about (I just need *some* working init). To re-iterate: are you worrying about innovation or about a lack of interest in breaking things? Best, Michael pgpboi9qipK1j.pgp Description: PGP signature
Re: Innovation in Debian
Heyya, Michael, On Mon, Jul 22, 2013 at 05:42:35PM +0100, Michael Tautschnig wrote: I do see that some innovative ideas cause breakage. And sometimes breaking things may result in progress. All I was saying is that innovation and breaking things are not the same. Granted. I 100% agree. However, innovative solutions which *don't* break things are usually welcome in unstable :) In an ideal world, people would come up with innovative ideas, think them through, and then come up with a plan that breaks as little as possible. (No, we don't live in an ideal world.) I do agree - however, allowing your work / plan to be fleshed out in the real world and allowing for peer-review (in a low-cost way, not in a rebuild-world with these patches and swap GNOME out way) is something that helps foster innovation / collaboration on real-world problems. (Oh, I see what you did there. Well, X broke, perhaps we can do Y and Z to get around that?) I tend to disagree, but I don't have any hard facts to back up my claim. Meh, neither do I :) May I dare to say you are lacking innovation here? Look at what Mika did in his Perhaps so! I do love better solutions :) kantan project (http://grml.org/kantan/). No, he did not stick his head in the sand when working towards testing grml. But actually all you need is a virtual machine. Or maybe not even that: just use http://collab-maint.alioth.debian.org/debtree/ which won't even require a single package build. Just look at (or automatically analyze) the output. While this is all great stuff (thanks, really, I didn't know about kantan) I don't think it's exactly what I need in this particular case I'd really like to be able to publish it for review, and even allow others to work with me (just dput it into PPAFOO if you're interested in helping, etc) on general package work. I fully agree with this point, but at the same time I'd hope that people go the might-break-things route only once they thought about it. Breaking things out of plain laziness is not acceptable. Sure. Keeping it to PPAs and keeping unstable as-is is likely one way to contain people going out of control (they'd still need to transition the real way in unstable) When (potentially) breaking things is the only way to achieve progress in a particular sub-project then this shall be ok. (Obviously a comment I should be making in other threads and likely there will be people who disagree.) But *please* don't push for a routine of breaking things as a general means towards progress. As I tried to show for your example above: there may be other solutions to a problem, and these may even be more efficient. This isn't anyone's personal sand-pit, so please be considerate of both users of fellow DDs by putting in a reasonable amount of effort to think about safer solutions. I do agree, but I also think that allowing DDs to break things in a small, contained section (e.g. PPAMAIN), we can help avoid bigger breakage by testing out the plan in the real world, with real-world conditions (etc) Best, Michael Thanks, Michael! Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Innovation in Debian
On Mon, 22 Jul 2013 16:22:37 +0200 Zlatan Todoric zlatan.todo...@gmail.com wrote: For me, unstable or experimental should be *just do it* and develop it so Debian gains momentum (or some other nice solution to gain that). Coordination is always the problem. Developers cannot just go and break everything for others by doing what they like without regard for anyone else. If everyone just did their own thing, everyone would end up being blocked by incompatible changes elsewhere. There is a bit less of a constraint now that we are outside the freeze but unstable is not and cannot be allowed to become a complete free-for-all, even only amongst those who have upload rights. All developers need to work with others to make changes and that's where all the arguments start, especially if someone wants to change the default something to something else. No developer is an island. Innovation in Debian, from my experience, has actually happened most often by getting lots of Debian people together somewhere with reliable network connectivity, a local mirror and a ready supply of beer, caffeine food. Face to face, a lot of the nonsense plaguing the lists just wouldn't happen. Some of it would, so sometimes we do need people who can just tell some of their colleagues to shut up and stop being an idiot too. It helps if those people are the ones with a reputation for getting things done themselves. If more people sat and counted to 100 before hitting Send, we may actually get a whole lot more useful stuff done. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Innovation in Debian
Hi, On Mon, 22 Jul 2013, Paul Tagliamonte wrote: I want the process to be something like: - New PPAMAIN - Upload new package - NMU packages to work with the new stuff (this needs to be something that the project is OK with) inside the PPA - Fiddle - Push it back up I expect that NMU limited to a PPA (even PPAMAIN) will be mostly non-controversial as long as they don't end up auto-migrated to unstable without approval from the real maintainers. So, to me, this service is certainly crucial to make it easier to innovate and increase our pace of development. Screwing with setting up servers is absurd. I just want to hack. I don't want to maintain the archive. I don't want to maintain the servers. I don't want to support build boxen. We need to find a way to get the boring stuff out of the way for people excited about change, and not try to box them into non-breaking changes only while they work out the kinks. +1 We can also do much better in making it easy to auto-setup all this infrastructure for derivatives. Having gone through the process for Kali, it's disheartening to end up picking reprepro and rebuildd because dak and wanna-build/buildd are too complicated to setup. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130722192835.ga1...@x230-buxy.home.ouaza.com
Re: Innovation in Debian
2013/7/22 Raphael Hertzog hert...@debian.org: Hi, On Mon, 22 Jul 2013, Paul Tagliamonte wrote: I want the process to be something like: - New PPAMAIN - Upload new package - NMU packages to work with the new stuff (this needs to be something that the project is OK with) inside the PPA - Fiddle - Push it back up I expect that NMU limited to a PPA (even PPAMAIN) will be mostly non-controversial as long as they don't end up auto-migrated to unstable without approval from the real maintainers. So, to me, this service is certainly crucial to make it easier to innovate and increase our pace of development. Screwing with setting up servers is absurd. I just want to hack. I don't want to maintain the archive. I don't want to maintain the servers. I don't want to support build boxen. We need to find a way to get the boring stuff out of the way for people excited about change, and not try to box them into non-breaking changes only while they work out the kinks. +1 We can also do much better in making it easy to auto-setup all this infrastructure for derivatives. Having gone through the process for Kali, it's disheartening to end up picking reprepro and rebuildd because dak and wanna-build/buildd are too complicated to setup. Indeed! For Tanglu, we use dak (with lost of help from ftpmasters while setting it up) and a Jenkins installation for package-building instead of wanna-build. Later, I think that paultag's set of tools will help a lot in setting up extra repositories and build services :-) Cheers, Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caknhny_gjtcpptih2tba_fuq1wzwqosanpsavnxw1ednj51...@mail.gmail.com
