Replying to [ticket:560 corsepiu]:

• With each Fedora release, a package gets inherited from rawhide into "released Fedora".
  I.e. when a maintainer is only interested in EPEL and rawhide (Because it's non-circumventable to him), this will result in defacto orphaned package in Fedora < rawhide.

No. Some maintainers actually feel responsible for their packages. That's my case, and once F15 is branched and the package gets there, I will maintain it there, even if that branch is not my primary interest. Ditto for future versions of Fedora.

That's also what I said in the review request.

• A new submission to "EPEL" and "Rawhide" means adding hardly tested packages to a supposed to be "rock solid" distro - This isn't in EPEL's interest.

Note that it will still have to go through the 2 weeks period in -testing, as for any EPEL submission. That's plenty of time for you to submit feedback. ;)

• Packaging a package for "EPEL" without packaging it for Fedora is counterproductive to the Fedora distro - EPEL's package offerings should be a subset of Fedora's offerings.

The package '''will''' be in Fedora. I will push it myself to Rawhide (that's still Fedora, right?) and maintain it in subsequent stable Fedora releases.

• Not packaging Fedora-packages for "Fedora releases" means a package is not receiving the user exposure and testing Fedora offers.

Is that a promise from your part to test and give feedback on each one of my package submission to a Fedora branch in Bodhi? :)

From a historical standpoint, maintaining a package in rawhide and future releases has been fine. Maintaining a package in EPEL hasn't demanded that a package wait until it is in released Fedora before.

If FESCo does decide that there is a question that should be considered here, note that there are other classes of package which exist in EPEL but not in Fedora at all. Some of those are due to orphaning in Fedora but not in EPEL. Others are intentional in that they are bringing new versions of libraries to EPEL where Fedora already has the newer version.

Adding meeting keyword here.

I'll agree with toshio here that historically this has been fine. There are cases where it doesn't make sense to ship something in fedora and is only targeted for EPEL.
Compat packages, alternate stacks (python26), software which has been replaced by something in fedora but RHEL is too old to use/build that thing, etc.

I believe we have number of maintainers who maintain their packages mainly in EPEL and we can't change it or control it by any policy. As was posted above there are packages, which exist only in EPEL. We don't need any policy for this issue.

Replying to [comment:6 mmaslano]:

I believe we have number of maintainers who maintain their packages mainly in EPEL and we can't change it or control it by any policy.
Certainly we can control this.

As was posted above there are packages, which exist only in EPEL.
This is not the issue I am talking about.

I am talking about people who drop packages into rawhide and leave them essentially unattended in Fedora, when these packages propagate to Fedora when time progresses, because they only take care about EPEL.

In end-effect these packages end up maintained by "other people" and not by the "nominal maintainer".

We don't need any policy for this issue.
I could not disagree more - If you want me to put it bluntly: I am tired of being exploited by package maintainers, who are expecting the Fedora maintainer will do their ground work.

I agree with mmaslano that we do need a policy for this. Without a written policy we may run into more issues such as this and have to deal with packages that are dumped into Fedora and then un-maintained.

In this particular case the maintainer is saying that they will maintain the package in rawhide (F15) and beyond as well as EPEL. I see no issue with that, with the understanding that the Fedora branches must be maintained, and co-maintainers should be solicited.

Pacakges for EPEL only should be restricted to a case by case basis and only be approved when the package does not make sense to include in Fedora.

Maybe we should look at requiring Sponsors to be co-maintainers for all packages submitted by the people they sponsor.

SMP

Replying to [comment:8 tuxbrewr]:

I agree with mmaslano that we do need a policy for this. Without a written policy we may run into more issues such as this and have to deal with packages that are dumped into Fedora and then un-maintained.

In this particular case the maintainer is saying that they will maintain the package in rawhide (F15) and beyond as well as EPEL. I see no issue with that, with the understanding that the Fedora branches must be maintained, and co-maintainers should be solicited.

Pacakges for EPEL only should be restricted to a case by case basis and only be approved when the package does not make sense to include in Fedora.

Maybe we should look at requiring Sponsors to be co-maintainers for all packages submitted by the people they sponsor.

SMP

Maybe we could co-maintain packages in groups/sigs ;-)

I know about few people who don't work less on Fedora, but I don't want lost contributor, who can help at least sometimes. So, I don't want create another strict policy, which is making contributing into Fedora more problematic.

-1 to this ticket if it's not obvious.

Replying to [comment:10 mmaslano]:

Maybe we could co-maintain packages in groups/sigs ;-)
You and tuxbrewr just volunteered to maintain all such packages?

I know about few people who don't work less on Fedora, but I don't want lost contributor, who can help at least sometimes. So, I don't want create another strict policy, which is making contributing into Fedora more problematic.
Turn this view around: I am not interested in people who are keen on wearing a "Fedora contributor batch" but otherwise rely on other people to do their work.

Lossing these people is no loss - It's an improvment of the quality of Fedora and a reduction of churn.

-1 to this ticket if it's not obvious.
Another FESCo mistake.

Fesco would like to re-iterate that package maintainers should follow all the responsibilities of being a package maintainer for all the branches that their package has. No requirement should be forced for which branches a maintainer can request at this time.