> 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
