Hi, > I think you have to consider that many people , including us, Bruno and > Carozo > are using HBQT to develope another library. > > Your disagreements can ruin a lot of work made in lasts months > > HBQT , HBIDE and HBXBP could become one of major GOALS of > harbour community , without underestimate , the great work of all harbour > community. > > I begg you all , to reconsider these changes , taking this in mind. > > I think that at least , HBQT must remain in Contrib, and with full support of > Harbour Community > > as an oficial Graphic Library . > > I know that is opensource software and I can't clame to anybody
All users should see that the URL (f.e.: sf.net/harbour vs. sf.net/hbqt) of a project (or library) won't make it less useful / sexy / used / developed or less desirable. It stays the same project, with same users and volunteer contributors. In fact, in separate repositories it can even flourish better, since there is no higher level or quality rules to adhere to, nor getting an agreement from other project maintainers. This give full freedom in the hands of developers. It also makes it that everyone can much better concentrate on the area he is interested in. It also makes things to scale much better. There are several good examples for this, in no particular order: HWGUI, MINIGUI, WXHARBOUR, LETODB, XHGTK. Some of these wouldn't be fit to Harbour SVN, because our stricter rules or portability requirements. Yet they are useful, users keep using them, developers keep developing them. Sometimes even Harbour developers are participants in them. Being part of Harbour SVN is partly a deal: It has some benefits, f.e. you get support and attention from core developers (f.e. i've spent several weeks on HBQT altogether), you get quality control, a build infrastructure, you have free packaging a release "service", more attention, etc. Most of these require a significant amount of time. So, in return IMO we rightfully expect for things to be more or less inline with basic project goals and rules and agreements. It also seems a natural thing that components like _Harbour core_ need much stricter quality control than upper level ones, since everything is based on them, and this is the key to the stability of the whole platform. While I personally believe that all components should have equally good quality to form a good quality end result, practice shows that this is sometimes not achievable in practice, due to limited resource or not enough interest in this area, even sometimes the time consumed would not be justified or even noticed at the end. I can accept that. At the end it comes out as: Is this deal worthwhile for all parties? If it's a time wasting struggle for quality on one end, and an uncomfortable feeling on the other end, what is the point? Users won't benefit either, since developers are wasting time instead of developing. The other option is to lower quality needs, not think about future, of redundancy of any form, priorities, or leaks, allow GPFs and allow design decisions which will have such a high "cost" in the future, that at that point nobody will be able to deal with it anymore. See HBWHAT32 for an example for that. For a solution IMO we should seriously consider to split Harbour into more parts, it has become huge and if this continues it will become unmanageable and rather sooner or later no quality can be guaranteed for some of its parts. BTW, HBQT related parts now account for nearly HALF of the size of all contribs. This is large. I also think this community did it's job to help bring HBQT + parts to a nice, usable level now, and it can perfectly stand on its own. I'm glad to hear opinions on how to solve these in other ways. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
