[cut-team] Using the CUT ftp server

Michael Gilbert michael.s.gilbert at gmail.com
Sun Feb 27 20:46:46 UTC 2011


On Sun, 27 Feb 2011 00:19:10 +0100 Stefano Zacchiroli wrote:
> So, Michael, by all means go ahead with your experiment (and thanks for
> it!), but please refrain from calling it "Debian CUT" for the time
> being.
> 
> I share Raphael's impression that your views are at odds with those of
> most of the other participants on this list, who include the people who
> started Debian CUT. There is nothing wrong with disagreeing, but I think
> those people have the right to choose what to use the name "Debian CUT"
> for and when. IMHO, this is so no matter what the current status quo is.

Hi Stefano,

Thanks so much for your feedback.  I know that I have initiated a few
discussions here that have been perceived as somewhat controversial.
Like I've said a couple times now, that has certainly not been my
intent. My goal was simply to air and refine some of the ideas rattling
around in my head. I have never been dead set on any of those, and I
have tried to be very adaptable to all of the feedback/discussion.

So, anyway, my current CUT incarnation is now the most conservative
approach that I can presently imagine, and that is based on all of the
feedback here. All it does is install a particular snapshot.debian.org
testing snapshot. There are no changes to testing/unstable or anything
else. I'm simply reusing existing project resources to create something
a bit new/different.

I think some of the present opposition has to do with my recent
discussion on kernel security, which is completely unrelated to my
proposed CUT release altogether. I only included cut-team as a CC on
that since I wanted to give those that may be affected by that idea a
chance to speak up. And they did, which is a very good thing. I've
pretty much dropped that pursuit for now.

Anyway, the current approach [0] (I believe) completely addresses issues
1 and 5 from Joey's original CUT manifesto [1], and actually issues 2
and 3 are already being addressed pretty well in the existing testing
infrastructure so no CUT-specific changes are required there. Issue 4
is still something worth pondering in the future as I mention in [0].

Finally, since my implementation is so highly conservative, I wonder
what it is that makes it "at odds" with the CUT team's goals?  My
impression is that no one has yet looked at the technical
implementation (which is incredibly simple BTW).  Without that, the
opposition's conclusion is based solely on past discussion about past
incarnations and other matters (a kind of straw man argument).  I'm
really trying to avoid making this paragraph confrontational, but I
want to stress that it's very important to be aware of the effect that
such logical fallacies have on the validity of argument before accepting
them at face value.

I would really appreciate it if those expressing such strong sentiment
were interested in directing some of that energy toward understanding
and contributing to the technical matter.  I think we could accomplish a
lot more if that were the case.

I really appreciate all of the feedback.

Best wishes,
Mike

[0]http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000232.html
[1]http://kitenet.net/~joey/code/debian/cut/



More information about the cut-team mailing list