Dear Russ, On Wed, Mar 31, 2010 at 06:19:13PM -0700, Russ Allbery wrote: > >> I don't wish to comment on the specific case of python packaging. > >> There's been lots of things going on there, and though some of it was > >> in public, the thread you point to clearly states that some things were > >> not discussed in public, but were instead only done through private > >> mail between some of the people involved. As such, it's impossible for > >> me to build a clear picture on what has been going on, which would be a > >> prerequisite for commenting on this. > > > Isn't this, by itself, a problem? Shouldn't it be very easy to find out > > what the discussions were, rather than have to ask those who discussed > > behind closed doors as to wha t the current situation is? I wish to draw > > your attention more towards this issue, rather than the particular case > > of python packaging. > > Insofar as disagreements are technical, I think they need to become > public. As with anything else about free software, more eyes are better; > plus, we have as a project goal to not hide our problems and to discuss > them in public.
Thank you for voicing your opinion.
> Insofar as disagreements are personal, I think requiring that they always
> be discussed in public has some implications that I'm not sure everyone
> realizes. By requiring that all personal disagreements be exercised in
> public, we would effectively be selecting for project contributors who can
> hold their own in vituperative public flamewars. I'm not sure that's
> actually a criteria that we should be selecting for.
>
> Obvious, in many cases, the two get intermingled badly, and I think that's
> probably the case here. In that case, it's often useful to bring in a
> third party to untangle the personal from the technical so that the
> technical can be discussed in public and we can reach a technical
> decision. But I would be very leery of applying the same problem
> resolution mechanism to all interpersonal problems that we want to apply
> to all technical problems. In general, and not here speaking about any
> specific case, I think that approach would drive away a fair number of
> people who would otherwise be valuable assets to the project.
This totally makes sense, but when it gets to the point where personal
disagreements and their resolution seem to stifle a significant part
of the community at large, this also results in disillusion.
In this situation, for example, I have personally experienced several
people asking me the trouble with getting python up to date in
squeeze, and have even had those people switch away from Debian
(arguably because they didn't want to spend time building and using
their own Python version).
More importantly, when it was said that some changes were needed to
accomodate package updates and facilitate smooth transitions, several
people went on bug filing and patching sprees which, even if not very
demanding in terms of skill, did take valuable time. Granted, that
there are always some problems which are not fit to be discussed in
the open, but, after we went through the whole process of preparing
for a future update, the standstill in further action does come as a
dampener to several, which is the root cause for some people to have
knocked the doors of the tech-ctte.
There may be no "this is the right solution" for this whole
problem. But I just wanted to know what the candidates thought they
should be doing, if anything at all, in order to help fix the
situation with as few bruises (ego or otherwise) as possible.
Thanks.
Kumar
--
I've run DOOM more in the last few days than I have the last few
months. I just love debugging ;-)
-- Linus Torvalds
signature.asc
Description: Digital signature
