Including the Apache maintainer in the CC.

Personally, I'm inclined to align with the maintainer on this. The patches in question are a set of upstream enhancements that upstream hasn't yet included in a stable release. If the maintainer is unwilling to take on the responsibility of maintaining unstable patches, I don't think it is sensible to force them on him.

In the Bugzilla you linked to, Joe Orton states "These patches are proposed for inclusion in 2.4.x upstream; because they are significant API changes we won't integrate them outside of an upstream release." I think that's a perfectly valid reason to defer them. New functionality requires additional testing and Joe most likely cannot put in the extra maintenance time that this would require.

Have you considered offering to become an Apache HTTPD co-maintainer? Joe might be willing to incorporate the patches if someone else is maintaining them (sorry if I'm putting words in your mouth, Joe).

As I said I ready apply and maintain these patches over time whan new release happened.

Also I stated in bug - there no "significant API changes" at all. Most functions and hook just optional additionals. So, no any breakage possible.

These three patches are in unstable upstream branch and it's not decided yet whether they will become part of the stable httpd. We can't be sure if they will hit the stable branch and future release as they are now in the trunk or there will be some further changes when more developers will review them before the merge or before the release.

Note that there was a discussion [1] recently (10 days back) on httpd-dev mailing list discussing some changes in the mentioned API.

Maybe you could try writing an email to httpd-dev mailing list to be sure the patches are included in upcoming 2.4.5 release.

[1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201306.mbox/%3C201306091157.55040.sf%40sfritsch.de%3E

1) httpd-itk is broken because the ITK MPM depends on APIs which do not exist in any released version of ASF httpd, nor any packaged version of Fedora httpd. So it is nonsense to imply that we "broke" the httpd-itk package.

2) What Jan said. And these patches are scheduled to be in 2.4.5. We aren't guaranteed that the API will be supported until 2.4.5 is out - and this is a new core API, so no, we're not going to support them via backported patches. When the API is supported upstream it will be supported in Fedora and you can use them in module packages. Wasting everybody's time trying to short-circuit that process, rather than contributing to the community is - still - a good way to burn goodwill.

Adding the meeting keyword.

In case I don't make the meeting, my stance is that I'm with Joe Orton on this one. It's incorrect to force the httpd package to carry unstable API enhancements to satisfy one dependent package.

@jkaluza

Note that there was a discussion [1] recently (10 days back) on httpd-dev mailing list discussing some changes in the mentioned API.
Please note, there discussion about change this new API, not anything stable one. Even if that happened it can't infere existing code.
I haven't found any discussion about revert and turf such patches which already in trunc.

@jorton

httpd-itk is broken because the ITK MPM depends on APIs which do not exist in any released version of ASF httpd, nor any packaged version of Fedora httpd. So it is nonsense to imply that we "broke" the httpd-itk package.

Meantime it was in previouse Fedora release and have worked! You promise new version introduce new API, but push new version '''before''' all dependencies will be able built against it. So it is broke.

[https://fedoraproject.org/wiki/Updates_Policy#AutoQA_Acceptance_tests_for_all_updates Our Update policy] for AutoQA said what updates '''Packages must not break dependencies''' for '''for all updates'''.

Pavel, your httpd-itk package is a fork of httpd 2.2. It has presumably been broken since we put httpd 2.4 into Fedora in February 2012, sixteen months ago. I am not going to take seriously the argument that we should not have put 2.4 into Fedora until your fork of httpd had been updated to be compatible.

Replying to [comment:7 hubbitus]:

[https://fedoraproject.org/wiki/Updates_Policy#AutoQA_Acceptance_tests_for_all_updates Our Update policy] for AutoQA said what updates '''Packages must not break dependencies''' for '''for all updates'''.

Just to note, that's for updates within a release cycle (i.e., all updates to F-17). Oftentimes we do have ABI/API breaking releases in new major releases.

Joe, MPM ITK '''is not fork'''! And never had been.

[http://httpd.apache.org/docs/2.2/mpm.html MPM] = Multi-Processing '''Module''' for Apache.

Esentially it have no sence. Even if it has been fork, present in Fedora repos and have you package as dependency it is your [http://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages package maintainer responsibilities], citing "you should try to help fix the packages affected. For example, if you're a provenpackager, queue the rebuilds yourself". But instead you compleately refuse fix it in any maner.

Just to note, that's for updates within a release cycle (i.e., all updates to F-17). Oftentimes we do have ABI/API breaking releases in new major releases.
I especially bold from citing "for all updates", please see original it is out of context "Stable Releases" chapter.
Off course between releases nd in rawhide we can have time frame with broken dependencies. But then it should be announced properly and coordinated effort to fix such issues (in Future or even in side tag). F.e. by [https://fedoraproject.org/wiki/Features/Policy/Status Future Policy] "Beta Freeze--all features should be 100% complete. If necessary, the feature page adjusted to reflect everything completed (so as to reflect 100% completion)."

A side tag was requested, and releng advised against it:
https://fedorahosted.org/rel-eng/ticket/5134

The change was announced on devel for discussion, well before release:
https://lists.fedoraproject.org/pipermail/devel/2012-March/164767.html
It definitely could have been a Feature, I suppose.

But, in any case, unless I'm missing something:

httpd-itk could work as it did before (by bundling/rebuilding httpd). To work as a loadable MPM, it needs to wait for a httpd release that supports the API it needs. And I'm generally OK with waiting until an upstream release that exists for it.

It's little bit unfair to say we haven't done anything (especially when I count in the time I spent on it...) to fix packages which were broken with httpd-2.4.

[https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=CLOSED&list_id=1457394&query_format=advanced&short_desc=Fix%20compilation%20with%20httpd&short_desc_type=allwordssubstr List of patches against components which failed to build]

[http://jkaluza.fedorapeople.org/mod_perl/ 24 Patches to fix mod_perl with httpd-2.4]

[https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=CLOSED&list_id=1460813&query_format=advanced&short_desc=Broken%20configuration%20for%20httpd%202.4&short_desc_type=allwordssubstr Remi Collet's 60 bugs for webapps with incompatible config file]

Every update of major version will cause problems, but I don't have the feeling we have updated and didn't care...

Joe, MPM ITK is not fork! And never had been.

That depends on the definition of "fork". It is definitely bundling httpd-2.2, patching it with custom patch and building it.

Maybe you can do the same with httpd-2.4 before the API you need gets released? I see tarball for 2.4 on httpd-itk pages.

@notting but as you see we have still dependencies and problems in transition (and effort provided by jkaluza confirm it too). So, it can't be threated as 100% ready future?

@jkaluza

It's little bit unfair to say we haven't done anything (especially when I count in the time I spent on it...) to fix packages which were broken with httpd-2.4.
I have not tried in any manner say what you do not do anything/something or cost you work in any case. Your work is very appreciated.

But in this concrete issue apply upstream commits as patches is quite trivial and it has been done in the past many times with httpd too. I can only repeat what I ready apply its himself if you are willing.

As I won't be able to attend today FESCo meeting - I am definitely with Joe Orton on this issue - backporting patches adding new features can be considered only when upstream release contains this feature.

This was discussed at the 2013-06-19 fesco meeting where we agreed:

Please bundle code in httpd-itk for now, build httpd-itk and once the upstream httpd version is released with the patches they need, they can build it as module. (+5)

Note that if you're going to bundle code, you'll need to get an exception from the FPC to do so. I'm hoping that you could get an exception if you specify a timeframe by which you'll no longer be bundling. As jkaluza mentions, joining upstreams' httpd-dev mailing list and trying to get the patches included in 2.4.5 would help with this (as then the FPC would have a more firm commitment of when the patches will be going into an upstream release.)

Sad to heard...

@toshio:
As it is not libs it is [https://lists.fedoraproject.org/pipermail/devel/2012-January/161271.html not forbidden] to bundle it.
There another problem, go to that way and be close to httpd itself (address security fixes, CVE, have same base functionality like config option, pathes and so on) I also need apply same patches as httpd does and goes in contra with guedlines about comments, because most of them does not have any comments in spec. I've [https://bugzilla.redhat.com/show_bug.cgi?id=225891#c3 ask add it even in Merge Review, but it also ignored for years].

But as I understand it is singl way.

Thanks for at least consideration...

I'm afraid you're quite wrong about the general case. In that thread, Jon Ciesla is an FPC member and Kevn Kofler is not. Jon said that the code could be considered under the bundled library guidelines. After further clarification from the submitter in the mailing list thread, it likely seemed that the code in question would be granted a copylib exception or perhaps generate a new exception classification as it appeared to just be copying a few routines from another application so it wasn't pursued farther.

If I'm reading the situation here correctly, httpd-itk is bundling all or significant portions of apache httpd. By contrast to the few routines above, that most likely would need to have a bundling exception. There very well could be other circumstances that would lead to this exception being granted or a new exception classifcation being created but as it stands there is no evidence of this. It's probably best to open the FPC ticket and give them the full information to come to a decision (and like I say, falling back on a time-limited exception is also an option).

A better example to show that bundling of applications is included in the Guidelines is the Gargoyle case: https://fedorahosted.org/fpc/ticket/202

If I'm reading the situation here correctly, httpd-itk is bundling all or significant portions of apache httpd.
No. It only contain source code and patches to produce self binaries, as it is not provided by httpd package. No any libraries or other stuff bundled in binarie package.

By contrast to the few routines above, that most likely would need to have a bundling exception.
It went via standard review process and I think it is correct. Feel free to open ticket if you are willing.

Futehrmore, after meeting fesco make conclusion posted above: "Please bundle code in httpd-itk for now, build httpd-itk and once the upstream httpd version is released with the patches they need, they can build it as module. (+5)" so exception also granted...

Replying to [comment:20 hubbitus]:

No. It only contain source code and patches to produce self binaries, as it is not provided by httpd package. No any libraries or other stuff bundled in binarie package.

Just checked the spec file:
Source0: http://www.apache.org/dist/httpd/httpd-%{version}.tar.bz2

This is bundled code following the gargoyle example above. As I've said several times, the FPC may be willing to craft a general exception case that fits this situation but at the moment your package is not in compliance with one of the major Fedora Guidelines.

By contrast to the few routines above, that most likely would need to have a bundling exception.
It went via standard review process and I think it is correct. Feel free to open ticket if you are willing.

Futehrmore, after meeting fesco make conclusion posted above: "Please bundle code in httpd-itk for now, build httpd-itk and once the upstream httpd version is released with the patches they need, they can build it as module. (+5)" so exception also granted...

The authority to decide upon allowed bundling currently rests with the FPC, not with FESCo. So you're looking at the wrong body to grant you that exception.

A proposal was raised at the 2013-06-26 FESCo meeting to have FPC investigate this and how it should be handled. See
https://fedorahosted.org/fpc/ticket/310

Looking at the original review request: https://bugzilla.redhat.com/show_bug.cgi?id=598860 , this package should not have passed review. In my opinion, the only way this code could be included in Fedora is how Debian did it, i.e. as part of the httpd package and that's up to its maintainer.