From: Jeffrey H. <jef...@aj...> - 2000-07-06 01:23:07
|
OK, you've got write access. core-8-3-1-branch is where 8.3.2 is going, but don't commit there just yet. Work on the mainline (which will be 8.4a2, to be released after 8.3.2. The mainline is also really a dev branch right now. Go ahead and make the commits there directly, since they should be innocuous. Of course, always test on as many platforms as possible before commiting. Although Duffin noted that the CVS dev branch is in a constant state of flux, we always try and make sure that things are checked back in before they are fully tested. For the moment, the plan is that if people want to work on new features that need CVS history, but may break things while in development, a development branch would be made for that feature, which would be brought back into the mainline when it was finished. Also, the idea for two-response OK and one-response VETO is in line with what we were planning. I noticed that you sent in a patch that basically was just compiler warning fixes (casts, decl cleanup). For these things, it should not be necessary to wait for approval. There are some casting cases where that might not be the case (like with ANSI casts, or when one needs to be careful because different OSes have different prototypes). Use your discretion in what can "just be commited" because we don't want to clog the process with menial things needing approval. And if something happens, that's why we have revision control. Jeffrey Hobbs Tcl Ambassador ho...@Aj... Ajuba Solutions (nee Scriptics) > -----Original Message----- > From: Mo DeJong [mailto:md...@cy...] > Sent: Wednesday, July 05, 2000 4:23 PM > To: Jeffrey Hobbs > Cc: tc...@sc... > Subject: RE: About mingw support in Tcl/Tk > > > On Wed, 5 Jul 2000, Jeffrey Hobbs wrote: > > > Mo, > > > > I agree that back-porting whatever build changes are necessary to > > 8.3.2 is a good idea. The 8.3.2 release is tentatively set for > > July 27th. It would be good if all the changes could be made and > > verified against 8.4a1 in the interim and then back-ported, so we > > don't break the 8.3.1 branch at any time. > > Great. I can get started this week, I am sure I can be done by friday. > There are still some problems that need to be fixed in Tcl 8.4, > but once that is done we will be good to go (the problems are > in the tclConfig.sh script for windows). > > > To this effect, it's probably easiest to give you write access to > > the core, if you want it. You'd have to resist the urge to > > reshape the core willy-nilly into Jacl. :^) > > You mean I can't add that path to parse [] as a literal string? Dang :) > > > Seriously though, > > we'd open it up for you to make config changes, but please restrain > > from making feature changes or finicky bug fixes without talking > > with us (tclcore) first. Hmmm, I think we'll have to make a real > > mailing list out of this soon for all with core write access to > > make sure people don't step on each others toes. > > The way it is typically done is that each patch needs to be > posted to a mailing list and then oked by two of the maintainers, > before it can be checked in. That way everyone on the list > (I assume this will be the tc...@sc... list) will > be able to see what is going on. The other rule is that if > someone objects to a change then it can not be checked in > until the objection is removed. > > > If you want access, tell me and I can brief you on the current > > setup and the best plan of attack. > > Sounds good, just switch my user over so that I can write > to the tcl and tk modules and I will be all set. Of course, > you will need to sign me up for the core list otherwise I > will not know if you have oked my patches. > > Mo DeJong > Red Hat Inc -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |