Hi Fred, Le 21 nov. 08 à 10:29, Fred Kiefer a écrit :
> What is worrying me more than this accidental things is the feeling > of a > growing split between our two projects. To start of with a personal > opinion, I think that Etoile is by far the more interesting project. > In > GNUstep we only try to reimplement concepts defined by Next and Apple > whereas Etoile seeks to come up with concepts for the future. So I > really understand why you are working on Etoile and not GNUstep, > although I choose differently. > > Now what are the signs I see for a split? > > - Etoile people stopped to contribute to GNUstep (code and bug > reports). > This may be due to GNUstep offering everything they need or because > they > prefer to fix problems in their own code and keep the changes there. I think we wanted to get this release out quickly, since the previous one was 15 months ago, and we also lacked some manpower as explained by David and Nicolas. In my case, the result is that I haven't followed GNUstep development very closely this year. Even if it's true I haven't contributed directly to GNUstep, I haven't stopped to submit bug reports and patches. The problem is that I failed to give regular feedback for these bug reports and I haven't updated my patch submissions to match the comments you made. That's entirely my fault, I'll remedy to that. We really depend on GNUstep, keeping changes as workarounds in Étoilé can only be done as a temporary solution. Moreover some changes cannot even be patched in categories. For example, NSOutlineView drag and drop isn't fixed in Étoilé, because the fix involves static variables and the only way to get it fixed is that I resubmit my patch. > There may be other areas where the code from the two > projects would need some more integration, but I am most ignorant of > that. (another bad sign) Aside of Camaelon and WildMenus, I'll probably have some requests for EtoileUI. For now, I'm not entirely clear on what the final needs will be, that's why I haven't made any requests in this sense. I haven't really worked on this framework since September. I'm going to be working on it again it and take this opportunity to eliminate the existing workarounds. In the next months, I'll also get a clearer picture of what can eventually be done at GNUstep level to better integrate EtoileUI and AppKit. > I think this drifting apart is bad for both projects. It has drained > GNUstep from some of its most active developers and contributes to the > stand still of GNUstep's theming interface. And for Etoile it leads to > problems when users try to install Etoile on a different version of > GNUstep than the one the code was tested with. It also results in > users > not getting bug fixes from GNUstep because of Etoile methods > overriding > that code not being adjusted. Yes. If we put aside Camaelon and WildMenus, the overriden code is really limited though. The only few patched methods I'm aware are in EtoileUI and may be two or three others in EtoileFoundation. > What about a shared review of code and concepts in Etoile that > proved to > be valuable and of interest in GNUstep and then an effort to > incorporate > the relevant parts of that back into GNUstep? Setting up once more a > clean interface between our projects. Yes, I agree we should do that. This would be better discussed on gnustep lists I think, but just to raise the topic… it would be nice if we could synchronize some of our next releases with the gui/back releases. What would be even better would be to have some changes (such as NSOutlineView patch I mentionned or Camaelon ones) merged as quickly as possible into gnustep-gui stable version once they get accepted. I don't know if that's possible because the changes are quite substantial. But this would allow us to get next Étoilé releases packaged for package system where only GNUstep stable versions are offered as packages. May be we can come up with some transitory solution over six months or so. Once Camaelon/WildMenus are almost fully merged back into GNUstep and EtoileUI is stabilized, the situation will be better, we should be able to rely on GNUstep stable rather than unstable. In the more-long term, we might encounter similar troubles with the text system when we start using advanced features. This could require a lot of changes to it or even a rewrite, hence to rely on GNUstep unstable to get Étoilé features work as expected. May be I'm wrong on this one though. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
