[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: pgpNoZcGfonFw.pgp
Description: PGP signature


Reply to: