Pavel Janík wrote: > From: Alexandro Colorado <[EMAIL PROTECTED]> > Date: Thu, 21 Apr 2005 00:58:45 +0300 > > > We can ask the question again, why does the patches don't get > > accepted? > > Are they submitted at all? Your question should be: "Why *submitted* > patches are not accepted?". > > The answer is: There are several possibilities: > > - patch is wrong thus the developer gets info what to change > - patch is OK, but in wrong time (see Joerg's mail) > - patch is OK and in time -> it is accepted.
Thanks for pointing this out, Pavel. IMHO it is necessary to see that not every patch can be treated the same way - and not every patch is a good one. Moreover a lot of patches we get can't be applied without additional work. Some of them have been created on outdated versions (f.e. the stable release, but we have to apply it to the development branch) or don't have the necessary quality, so additional code work is necessary. In every case the patch must be tested on all relevant platforms, sometimes specs or documentation have to be changed etc. But the biggest problem indeed is what Joerg pointed out: people don't understand that the patch can be accepted, but only for the current development line, not for the "stable" version. A very good example for this is the Gnome File Dialog integration into OOo. We got a "patch" for this, first without any specification and (obviously) only little QA work done. Though this created a lot of problems on our side and it arrived somewhat late (for such a big feature that was not completely done at that time) we accepted it for the next release (OOo2.0). In spite of several months of additional coding also on our site and a lot of QA work done by us the implementation of the feature still does not have a quality that makes it acceptable for real production work, so we had to disable it by default. Another problem: the first version of the new WP filter contained a nasty bug that lets OOo crash when any file without an extension was loaded. This does not mean that we shouldn't accept such patches/features, but examples like these clearly show that accepting patches can't not be done by taking the code and applying it to the code base. That said, I see it as unfair not to respect that developers hesitate to accept changes for the current stable release. I as a "core" developer can't hack something into this codebase just because I like it because we want to maintain the release and its quality with a *manageable* effort - why should other developers get a privilege that the "core" developers don't have (and they don't have it for a reason)? Moreover, I for myself can't just add something even to the current developer release without going through some processes (like requirements analysis, specification etc.). I know and support that this shouldn't be necessary for "external" developers to the same extent, but OTOH it should be respected that we need to judge received patches carefully. I know that some OOo distributors are not so reluctant - but I also know that from time to time there are complaints about strange things that happen in OOo, but not in the "official" version, only in some special breeds. It will be interesting how this works out in the long run. And BTW, OOo is not the only OS project that suffers from problems with external contributions. I'm a diligent reader of the Mozilla newsgroups or mailing lists (developers and users), and there are a lot of complaints about the slow acceptance of patches also. Moreover, the general willingness to work on fixes for bugs brought up by the community seems to be even lower than in case of OOo (though we all know that in our case it's also possible to improve it :-)). This tells me that there is a general problem of complex OS projects that are mainly done by a core development team. The complexity of the software (this is different to the complexity/opacitiy of the code base!) makes if necessary that the development process must be managed in a way that usually has been developed over years. As I read some time ago, a project like KOffice that is developed in a more open way (f.e. because it already started as an open project) also complains that they get too few developers - maybe this can show us that this is not a result of missing "opennness", but mainly a result of the complexity of the software that lets developes shrink back from it? "Free" developers very often prefer smaller projects, just because it's easier to enter them, it's easier to understand them, it's easier to add own contributions (and get the credits :-)). I think that's quite understandable and of course it's OK, but that should be seen when we are discussing contributions to OOo (or the lack of them). Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
