Am Donnerstag, 04.12.03 um 22:36 Uhr schrieb TheSin:
Already stated I will no longer work be working on fink's code base unless it's to fix something that I created.
That's not what I asked you for, but of course it's your own decision on how you want to react in this situation.
Sorry to try and advance fink instead of complaining yet again about something that has been discuss a dozen times already.
While I applaud your attempt to fix something which has been discussed a dozen times already, that is no valid excuse to at the same time ignore things which have been discussed a dozen times already.
The real problem, however, is what I see by looking over the fink-cvs logs in the past couple days. Essentially you seem to be doing some kind of trial-and-error development on the trunk right now. This is *not* good. Code should be tested before it is committed, not after. Of course it's very easy to overlook a mistake and accidentally commit it, happened often enough to me. But looking at your recent commits and also the commit messages, I get a really bad feeling in the stomach.
BTW, changing some fundamental behavior of fink w/o *any* discussion, or at least announcement of that change, on fink-devel, is *really* bad.
I have two branches already they don't work, they have been there for over 6 months, no one tests them and no one merges/updates them.I think we have a misunderstanding here about how working on a branch works.
A branch is a way to separate and isolate development of potential hazardous features from regular development. Once a feature has been completed and sufficiently tested on a branch, it may be merged back into the trunk, if desired.
A branch usually has one or more drivers - persons "in charge" of that branch. This person or persons develops the branch, and watches any changes made to it (in this scenario this is mostly redundant to mention, but on bigger projects it can easily happen that a branch develops branches of its own. But I digress). The driver is the one who drives testing of the branch, too - that entails getting others to test his branch. The driver may attempt to keep his branch in sync with the trunk to make merging it in the future as easy as possible It also means the driver is the "driving force" behind getting the branch merged into the trunk. Usually he does so by convincing the trunk maintainers that his changes are stable enough and useful enough to justify inclusion in the trunk.
A typical approach to that is that the driver decides his branch is "good for go". He then might make a patch against the trunk, and then post that patch in a patch tracker item for review / general testing.
As I stated it's the task of the branch driver to get others to test his branch and review it. Including the people responsible for the trunk. It's *not* the task of the trunk drivers to do this (they may do it if they feel like it, of course).
So, rather than complaining about you already having two branches which are there for over 6 months, *do something*. Decide whether you want to abandon these branches, or keep caring for them. In the latter case, go and fix them. If you can't do it, actively try to get other people who can fix them to help you. Once your branch(s) are fixed and actually useful, make a patch out of them, post a patch tracker item. Don't forget to put a description of your patch in that item, including an explanation of what the patch does, why it's useful, etc.. Then start prodding me/Ben/drm/etc. to review it.
That is an informal overview of how such things usual are handled "formally". Of course many things in there can potentially be shortcut, e.g. if you can get "trunk maintainers" to work together with you on the branch. However, just sitting there and hoping that somebody discovers one of your branches, tests it, makes required fixes for you and completes your code, isn't sufficient.
Directly including your changes into the trunk in the hopes that by putting semi-broken code into trunk, people will *have* to fix it for you and complete it, usually is a bad idea. A good example of this is something I did (putting in the "fink cleanup" code incomplete, in the hopes that somebody else will fix it). As you can see, that didn't work out too well. But at least in this case nobody will have to suffer. Luckily, the BuildConflicts field shouldn't cause suffering either, no matter how it is implemented, as long as it isn't used (and since it's not documented, it won't be used).
AFAIK one of your branches was about making passwd obsolete. Very good that you are working on this. The way it was done isn't quite the way I'd have liked to see it done. That wouldn't matter, though, if it worked. As it is, the code doesn't work and is very outdated compared to the trunk. So it's very hard for interested parties to try it out (the lack of any docs doesn't help). As a result, nobody does. If you are really interested in getting this done and merged, work on it, don't hope on a miracle (because sadly, the miracle always never happens).
Cheers,
Max
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
