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
Attachment:
signature.asc
Description: Digital signature