Hi Danny, Am 28.03.2012 um 23:49 schrieb Danny Terweij | LxCenter:
>>> So a lot need to be resolved before it builds like it should. >> >> "like it should" is subjective. It still builds the same as it always has, >> unless I'm missing something here. >> > > We could get no new data if there was not a successfull remake of a Makefile. > That means it uses a old Makefile. It could work but it can also give > problems. > Before i ever release a new RPM to the public or testing persons, it has to > be free of any kind of errors. Also it is a good point to always follow some > rules like SPEC rules. Even if it is a minor change, you can always refactor > the SPEC file a bit. > It is a kind of a odd thought that you say "still builds the same as always" > .. it can go very wrong at some day that you push a new rpm to the public and > odd things going to happen. "still builds the same as always" refers to the fact that you can follow the wiki article on how to install a new toaster on CentOS 5.x from scratch and it will work. I took the time to test that on a VM because I was curious if anything had changed since the last time I checked. >> While I agree that QMT package dependencies are a bit of a mess and too >> tightly coupled, we're not aiming to fix that up quite yet. Simscan in >> particular might eventually be replaced with amavis-new, so at this time we >> won't be doing any more with it than getting it as up to date as possible. > > I think i go stop distributing toaster packages to our community. To much > changes in the future and bad/poor written SPEC files. I appreciate the criticism and I think we're all aware that, as Eric put it, the dependencies are indeed a bit messy. However, if you are able to discern what is wrong with the spec files, why don't you contribute to the project and submit n updated version? I am sure everyone would appreciate the help. >> Thanks for your patience and understanding (and participation). >> > > No problem, but the patience is out of stock. Its better for our community > that we split here and maintain our own qmail and related packages. > I saw a whole new djbdns at githib pushed 3 days ago. Much promising and > finaly someone refactored it during the last 3 years. I bet the same happens > with qmail and other old packages, at some day. New life in kind of (good) > old software. I don't really get where you're coming from, here. Let me state a couple of facts first: - QMT is a group effort. - Participation and contributions are always welcome! - No one here is being paid to work on QMT (although QMT enables some of us to make money). - We have way more things that need fixing than people with time and knowledge to do so. In short: QMT is not a commercial product you bought and can now 'demand' support for, but rather an open source community effort that is open for everyone to help make things better. So why talk about splitting / forking when all that seems missing is your contribution? Best, Martin
signature.asc
Description: Message signed with OpenPGP using GPGMail
