On Thu, 07 Feb 2008, Szakáts Viktor wrote: > Before I read through your mail, let me note this is group > work, and while I'm familiar with some parts of it, I'm > not with some others, and no such implications (namely > the tie in between lib name and dir name in core) were > visible (or noticed by anyone), before the fact. I don't > think killing anyone would solve anything, but before you > jump to my throat notice that I haven't touched any central > GNU make (.cf) files, _only_ 'Makefile's LIBNAME line. > I doubt the file loss was the result of that.
Viktor, I know that it was not intentional and I only express my bad feeling. Sorry if you take this part personally. In fact the dangerous modification was done by Ryszard but such things may happen when you are forcing deepd modification in "last minute". I though that e agree that only things which are well tested and will not break release process should be commited. If sth cannot be done in safe way it should not be commited. AFAIR when few weeks (months) ago we want to release binaries you also have some "fixes" on the last minutes. Just for you information - I know some real bugs which have to be fixed but I do not commit anything because I'm waiting for the end of release process. This bugs are not citical, only few peope knows aboout them and in few cases it's a risk that I'll start some long process of fixes. Please release the new version ASAP. It will make many people happy and open the doors for developers for farther modifications. I have no doubts that next Harbour version will beat the older one even if it will have to introduced some fundamental modifications in core API. I'm usually quite pedantic in code I make public but it's not my life goal but the result of some practice. I hate bugs which are results of nested bad design decisions. In longer terms programmers have to spend more time on bug fixes then on productive work. But I've never wrote a code (probably with only one exception written directly in machine code even without any assembler) and I was happy with it and I couldn't say that nothing can be improved. If we agree that it's time to make release then it's compromise - common group decisions. It was possible to release version 1.0 half year ago. It's a time without any new extensions when all developers are waiting for a time when they can introduced new (often long waiting) features. And we do not even finished base modifications like MT mode which may stronlgy interact with existing API so even todays modifications may be temporary. It's normal and good because it means that Harbour is living project. > I'm sorry if the whole process resulted in file losses > for you :( Unfortunately bumps are expected, even if I > find it odd that our make system can be such a dangerous > beast. It was nothing more then a typo which can appear in any make file in any project. It's a risk of using development code. And this is the reason why such modifications should never be done in few hours before final release when we ask many people to make build tests. I thought that you are one of the last person who will do sth like that. > I had actually expected (but definitely hoped) you to take > part in this rename process because of your different > environment and skills, especially after you've agreed > and even gave input to it. I agreed only with a condition that you can make it well without breaking release process. I simply though that you will change library names synced with directory names. > About a "simple file rename" I don't know what you > meant, but if you had exposed this idea _before_ > or _when_ we've been discussing the rename stuff, > maybe could have a better solution. I'm not the original author of Harbour GNU make system. I know how it works because I invested some time to look at it and I though it was clear for every one. Especially for you because few weeks ago I send you a message about this problem when you were updating contrib libraries. > About GTI_ and HB_GTI. GTI_ violates one important > rule and nothing was removed, so either on C and > Harbour level everyone can still use GTI_, despite it > being an xhb compatibility set of #defines imported > to Harbour. So the path is there for the Harbour compliant > way, yet no one suffers from any drawbacks. Where do you > see a problem? Mix of functions and symbols which comes from Clipper and Harbour. The Harbour ones have HB_ prefix and the Clipper ones don't. Only people who perfectly knows all Clipper functions can understand why some things needs HB_ prefix and why some others don't. Why we have DBI_* and why HB_GTI_*. Not all Harbour users started with Clipper and even not all Clipper user knows Clipper enough to understand some things. If we will be too restrictive in some case then finally it will be necessary to rewrite all core functions with alternative name having HB_* prefix. Then finally someone will implement name space support (f.e. some initial version was created for xHarbour by Ron recently - it's not exactly what I want but perfectly shows the possibilities) and will ask us why we introduce such redundancy with HB_ prefix in all possible places which now cannot be removed due to backward compatibility. I do not want to allow to add anything to core code. xHarbour has many public functions which should never appear in core code with such general names like NetDbUse(), NetLock() because probably most of us has sth similar so they do not add anything valuable but are possible source of conflicts. But if I'm adding yet another ord*() functions then I do not want to call it hb_ord*(), f.e. ordCount(), ordWildSeek(), ordKeyRelPos() because it will not help anyone and only increase the problem with cleaning the code in the future. > >1. authors of these two libraries intentionally keep binary > > compatibility for years to avoid such problems so in this > > case you haven't help any one but only created new problem > > by removing them. > It's still not legal, and it still raises some other concerns, Brian, can you ask extended system if we can have ace.h in our SVN/CVS repositories? > and binary compatibility is by far not guaranteed, what happens > with the new functions added to ADS8 .h file, when someone is > using an ACE6 .dll with it? What happens when someone is passing > a non valid (later introduced) #define with an existing function? I do not know about any problems which may be cause by this header file in current code. Do you know any? > If someone wants to create a release (which supposes some > familiarity with both Harbour and it's contribs and make > systems), is it a very high expectation to set a few envvars > and to have these two packages installed? I believe you will find people for it. Good luck. > You still haven't answered what are the "serious problems" > these "missing" headers can cause. I'd really like to see them :( I was testing about 15 different builds of Harbour and braking this process is a serious problem. If I will have to hack each cross build test to pass new condtions then it will stop be real tests. But it's not longer a problem because I do not plan to make such test in the future. I've just created a repository for my own use so I do not plan to repeat such tests current official releases. > >2. when we finished release process then you can remove them. > > I will not be longer interested what will happen in the main > > branch because I plan to create new one only for development > > If you will find anything useful then you can borrow it to > > official branch. > I'm not exactly sure what do you mean by that? An internal fork? Call it as you want. Of course it was only a proposition. I do not have to public my work. I haven't ever had any incomes from Harbour or xHarbour other then using some part of my code in my business work. Now I plan to concentrate only on this last aspect and I plan to leave most of core code modifications for others. Only few things I started and I do not wast the invested time I want to commit. > >And please also look for someone who will continue release process. > >I'm afraid that I do not have more time for it. Now I have to restore > >many things I lost which are important for me. > :( > I feel our GNU make system is flawed or overcomplicated if it can > cause such things. It's not GNU make problem but result "last minute" modification. I can reach such results by small typo (one /) in non GNU make files too or by wrong setting some variables. It happened in GNU make system because it's for much more platforms and compilers then others so the risk of stupid mistake is much bigger. Finally: it's nothing personal to you or anyone - you made increadible and valuable job for this project. Just simply I think now it's a time to look for other people work (maybe I'll find sth interesting for me) and move focus to some other things. For sure I definitely do not want to be a person who will have to prepare new release anymore if I cannot control this process at all. Wake me up when 1.0 will be ready. Meanwhile maybe I'll help in some minor problems but I cannot promise. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
