> Costin Manolache wrote:
> >
> > This whole "become a commiter" is not that easy
>
> Tell me about it. Perhaps you remember when I first tried to get a few
> patches applied to a subproject named Tomcat. ;-)
I'm glad you still remember ! And at least one person on this list
understands ( or should understand ) my point.
> I am quite prepared to think outside the box here. In a matter of seconds,
> I could update the avail file to make anybody who is a committer to one
> project a committer to all. And as chairman, I probably could push this
> through. That's how PHP development works. If you want a chuckle, take a
...
> The path to success here is to start small with a few trailblazers. Make
> (or steal <grin>) some code that everybody sees value in. This will create
> a pull. Use that to broach the discussion on the larger topic and request
> a bilateral exchange of commit rights. Once you start swamping the people
> with cvsroot authority with requests, the solution of merging all of the
> lists will become obvious as the solution.
That was exactly my point - except "make" some code, I don't think the
lack of valuable code is the problem.
We need a place where every other project can move part of it's
code ( without fear of duplication or having to convince library
maintainers to accept the code ). We can then start fighting on foo-dev
to move some of the components ( 1/2 of tomcat code was redesigned
with this idea in mind - to be able to either share or replace ). And I'm
sure other projects will share some code - and hopefully we'll have
duplication ! And when something is duplicated - you have a choice, and
because the library can be viewed as "neutral" place, we may be able to
use the best component or merge the ideas.
The big difference is:
In one case, you create/get some components and try to convince projects
to use them.
In my proposal, you try to convince projects to move some of the code in
the common place and keep working on it there.
We can try both, but I think my proposal will get us more than just
components.
> set of circumstances and then strike. I personally see versioning as a
> major issue. There are many people unsure of the wisdom of treating the
> set of code bases as a whole, and insist on only building their little
> corner of the world against stable, released versions of everything else.
> (Yes, Costin, this comment was directed at you <grin>). The only way I
Yes, Sam, but we have release plan for tc 3.3 with a beta in few weeks,
and I can hardly track changes from ant1.3 to ant1.4 - treating the code
bases as a whole is wise, but also crazy ( and I have a lot of admiration
for whoever is able to do that ).
I know my limits, and I have a bit of experience building projects - I'm
sorry, but dealing with all the changes at once is over my capacity, so
I'll have to stay in a little corner where I know that at only few
walls are moving.
> know of to get people's attention is not with general theoretical issues,
> but with real concrete versioning incompatibility issues. Once they are
> see a few of these, they will be hooked.
I am hooked - but I have only so many free hours per day, and I have
enough versioning madness to deal with ( I just updated my linux, and it
already took me a week to get everything back in place ).
Costin
