On 12/2/05, Martin Cooper <[EMAIL PROTECTED]> wrote: <snip> > > > > In the "old days" we kept lf line endings on all the source files in > > cvs and hand-rolled ant scripts were used to put crlf on the .txt > > files in the zips. Between maven and svn's eol=native, that is no > > longer possible or at least immediate. The real question (see other > > response) is do we care about this? From lack of response to [poll] > > thread, could be the answer is no. > > > This is an interesting comment, and indicates that we haven't done things > consistently across Commons components (which isn't altogether surprising). > All along - including in the old days of CVS - I've worked with CR-LF line > ends, and that includes quite a few releases of several different > components. So with the change to SVN, I haven't been doing anything > differently...
See other thread. In the CVS days, commit diffs would flag CRLFs creeping into sources, so we did not need to worry about this. Windows editors would only hose files if set up incorrectly, so we were probably fairly consistent in what we released. Now, the svn client is "hosing" these files silently when you check them out on Windows (at least, IMHO), so by "doing nothing special" Windows developers are introducing inconsistency. > > > > > > These are really demotivating things! > > > > > Agreed and sorry if we seem to be making things harder rather than > > easier. Patches - or direct commits to - the releases page and any > > other suggestions to make things easier are most welcome. > > > > > > > One other comment that I have on the issue of voting on releases is > > that the core problem here is lack of component-committed volunteers, > > IMHO. I remember a couple of years back when we discussed whose votes > > were binding on component releases. Hen made the interesting comment > > that he felt that committers not working on the component should vote > > and their votes were as important / even more important than those of > > the project team. We have now devolved to the point where without > > these votes, we will in some cases not be able to get 3 binding +1's. > > This is not good. Somehow we have to reengage as Rahul pointed out at > > the top of this thread. > > > IMO, what this tells us is the Commons isn't scaling, and that doesn't > surprise me at all. In the "old days", there were a *lot* fewer components. > Right now, I count 35 components in Proper and 9 more active components in > the Sandbox (excluding the ones Henri is about to make dormant). That is a > lot of stuff! Very few people, if any, are going to keep tabs on all of it, > and most are likely to only track a handful, if that. > > When Commons was much smaller, the community was much more integrated, in > that there was more overlap between the pieces (people-wise, not code-wise), > and so we all watched each others' backs. We're no longer in that state. > > The inability to scale, is, in my opinion, an issue the ASF as a whole is > also facing. Unfortunately, as with Commons, I don't have any good ideas. > Other than to consciously stop growing, that is, but that doesn't appear to > be a popular direction. > I agree that it may be unpopular, but I see restricting addition of new components and archiving abandoned ones as the only realistic option at this point. See the recent [feedparser] thread as a pathetic example. I thought about voting -1 on promoting that component from the sandbox because I did not see sufficient community support and in retrospect I should have done this. I have not pushed to get [id] promoted for the same reason. We also need to concentrate hard on getting more volunteers to jump in to working on the existing set of components. Robert and Hen pointed out that making the components more approachable and some straightforward "jumping in" tasks available would help. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
