commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: [all] Together, and bricks apart
Date Sat, 03 Dec 2005 21:55:09 GMT
On 12/3/05, Phil Steitz <phil.steitz@gmail.com> wrote:
>
> On 12/2/05, Martin Cooper <martinc@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message