Re: [Tinycc-devel] Development/patches - subversion repository

[Nick]

Hi Fabrice, Rob,

Fabrice - thanks for making TCC open-source - great project!

> My earlier question: what patches did you apply to your svn?  Fabrice said 
> that CVS has only had two patches applied since the last release.  Possibly I 
> can navigate the CVS web thingy enough to figure out what they were.
>   
The svn tree is an exact image of the CVS top of trunk. It was created 
by importing the last official release, creating the svn trunk, 
importing the CVS top of trunk, and then merging the changes to svn 
trunk. I took this approach to allows diffs back to the last official 
relese. I have not applied any community patches yet.
> At this point I'm pretty happy with an Andrew-Morton style repository.  "Take 
> the last release and apply these fifteen patches in order".  Let's worry 
> about getting stuff in source control once we've figured out what patches 
> should be in it.
>
> I should scrub the list archives to see what's out there, and check Dave 
> Dodge's list against cvs.  (No, I do NOT have time to maintain another 
> project...  But I can help.)
>   
That would be great.

If a patch has already been posted to the mailing list and discussed 
favorably then please commit it.
If a patch has not been discussed on the mailing list and is not obvious 
then it would be good to post it for discussion (ie treat it as a new 
patch).

I have a few patches to post as well.

> > or a small project like TCC I figure it can work as without one person 
> > as a maintainer. I don't particularly like the single-person-maintainer 
> > model and that is why I am not volunteering to be that one person.
> >     
>
> Which sucks, because we need that one person and you're the closest we've come 
> this week.  (You at least set up an svn and offered to apply patches.)
>
> A good wedge only has one point.  But at this point I think the priority is 
> figuring out where the current slush pile is and what's in it.  Which patches 
> are candidates for being applied?  (The closest I've seen is Dave Dodge's 
> list...)
>   
A good wedge only has one point. Good advice if you want a wedge :-)

If people are using TCC, and take the time to fix something, then their 
goal is to make things better (unlike the Wikipedia example where not 
everyones goal is to make things better).
All patches should be posted and reviewed. Testing can be handled by 
submitter running the tests (if they have the setup), or by commiting to 
a "test-pending" branch that gets merged to the trunk every few days 
after a test run by someone who does have the test setup.

I figure people won't abuse checkin privileges, and if they do, just 
back out the problem. Write access requires a login and password so 
everything is tracked by author.

Much of my day job is working on/developing closed source code. Everyone 
in the company has the goal of improving things and we don't need or use 
a wedge for checkins.

It would also work by having a volatile trunk/branch and for Fabrice or 
a maintainer to do the final review and release management. The diff for 
a release could be applied back to the CVS version if desired.

I am completely open to ideas.

Nick