On 12/3/05, Phil Steitz <[EMAIL PROTECTED]> wrote: > > 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.
Also, see other thread. ;-) We seem to have had totally different CVS experiences. I did *all* my CVS work with CR-LF line ends, and I still have locally checked out CVS trees to prove it. Nothing - *nothing* - has changed with the move to SVN. This whole thing is a non-issue to me. -- Martin Cooper > > > > > > > > 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] > >
