We've done a fair job of attracting Fedora packagers to EPEL.
Now we need to get all the other audiences to get involved, as package users, packagers, testers, and general community members:
* General end-users * Academia and scientific users * Software and hardware vendors * General corporate users
I'll take the lead on this task, but boy do I need help and ideas.
Can we cook up a list of requirements or goals, so we can take some ideas to f-marketing-l to discuss publicity etc.?
Note that there are connections growing between f-marketing-l and Red Hat's marketing groups. That means this is a good time to exercise that relationship, since the target audiences are very similar for both marketing groups.
cheers - Karsten
On Nov 21, 2007 2:21 PM, Karsten Wade kwade@redhat.com wrote:
We've done a fair job of attracting Fedora packagers to EPEL.
Now we need to get all the other audiences to get involved, as package users, packagers, testers, and general community members:
- General end-users
- Academia and scientific users
- Software and hardware vendors
- General corporate users
I'll take the lead on this task, but boy do I need help and ideas.
Can we cook up a list of requirements or goals, so we can take some ideas to f-marketing-l to discuss publicity etc.?
Note that there are connections growing between f-marketing-l and Red Hat's marketing groups. That means this is a good time to exercise that relationship, since the target audiences are very similar for both marketing groups.
cheers - Karsten
Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
If this somehow means getting more packages into EPEL, then I am all for it. I hate to advertise too early however for the general user of EPEL. Right now several packages I use all the time are not in EPEL and my team keeps asking to use other 3rd party repos. I am not sure what the package count differences are between FC6-extras and EPEL EL5, but I would be it's almost half. I know most perl stuff isn't there (though that's getting better) and many other projects just haven't moved.
I would like to send out emails to the package maintainers one more time, wait X days and then just branch them and have new co-maintainers added in EPEL land. We need a full repository before we can advertise too much. We're heading the right direction, and are probably still ahead of critical mass adoption of EL 5, but we need to hurry if we want EL 5 users to use EPEL and not come up with their own solutions. (which they might need to do anyway).
I am happy to help somehow though. Next week I am hoping to get a list of the most requested packages from my company and at least get those contributors notified that we would like their package in EPEL.
Of course this really doesn't account for EL4, but I tend to think most organizations have found their solution for extra packages for their EL4 systems by now. The picking is rather thin there for EPEL. Maybe we could put some concentrated effort in there also. (Offer to co-maintain or help packages build on EL4). I know I had to change the BRs on several of my packages to work with EL4.
Anyway, enough rambling and ideas. As always, quaid, brilliant ideas.
Let us go forth and execute,
stahnma
On 23.11.2007 16:04, Michael Stahnke wrote:
On Nov 21, 2007 2:21 PM, Karsten Wade kwade@redhat.com wrote:
We've done a fair job of attracting Fedora packagers to EPEL.
Now we need to get all the other audiences to get involved, as package users, packagers, testers, and general community members: [...]
If this somehow means getting more packages into EPEL, then I am all for it. I hate to advertise too early however for the general user of EPEL. Right now several packages I use all the time are not in EPEL and my team keeps asking to use other 3rd party repos. I am not sure what the package count differences are between FC6-extras and EPEL EL5, but I would be it's almost half. I know most perl stuff isn't there (though that's getting better) and many other projects just haven't moved.
I would like to send out emails to the package maintainers one more time, wait X days and then just branch them and have new co-maintainers added in EPEL land.
That's IMHO the wrong way -- if we have people that want to act like co-maintainers in the way you outline then that people should look out for packages they might want to maintain in EPEL, ask the Fedora maintainer if he or she is willing to maintain that package in EPEL. If the Fedora maintainer then does not answer or expresses that he or she is not willing then the people you have in mind should become the EPEL maintainer (aka co-maintainer) and request the EPEL branch. I'm optimistic that above should work, but it likely needs some to drive and coordinate it. Actually I have that on my todo-list, but didn't get around to it. :-/
With the way you outline I fear we might end up with lots of packages in EPEL without maintainer or with maintainers that have to take care of hundreds of packages or packages that they are not interested in.
IOW: I think getting bigger is important for EPEL, but getting big to fast is not good for the quality of EPEL.
One thing that would be helpful here is a slightly easier way to get sponsored -- currently you have to submit a package to Fedora to get into a position to be able to maintain packages for EPEL. That hindering and likely not what some EL-only-contributers want (¹).
[...] I am happy to help somehow though. Next week I am hoping to get a list of the most requested packages from my company and at least get those contributors notified that we would like their package in EPEL.
Sounds great!
Of course this really doesn't account for EL4, but I tend to think most organizations have found their solution for extra packages for their EL4 systems by now.
Agreed.
/me suspects smooge might disagree, and he has a valid point, but I think getting EPEL4 big is a big task that requires much work; I'm not sure if that's worth the trouble. But If people show up to do that work: sure, why not!
CU knurd
(¹) -- if you are a EPEL user and not a Fedora contributer yet but want to maintain existing Fedora packages for EPEL please let me know in private; I'm sure we can find ways to get you sponsored.
On 23.11.2007 16:04, Michael Stahnke wrote:
On Nov 21, 2007 2:21 PM, Karsten Wade kwade@redhat.com wrote:
I am not sure what the package count differences are between FC6-extras and EPEL EL5, but I would be it's almost half.
Well, I was curious and took a closer look. Actually I compared 5Server + EPEL against Fedora 8 and not FE6, which makes EPEL even look worse. When looking at the source rpms I get this result (rough estimate which may contain a few packages detected wrongly, but should be good enough):
$ wc -l rhel epel fedora8 1085 rhel 819 epel 4803 fedora8
I ran "grep -v" over it and uploaded the list of packages that are in Fedora but not in EPEL to: http://www.leemhuis.info/files/fedorarpms/MISC.fdr/missing-in-epel
2986 packages ;-)
Some of them would be nice to have. Just took a quick look at saw for example:
abiword, airsnort, alpine, amarok, audacious, bluefish, [...], ipw*-firmware, [...], 527 different packages starting with perl, 69 starting with python, [...], xfce*, [...]
Note that a part of those 2986 packages are not interesting for EPEL; those 31 hunspell dictionaries for example.
Cu knurd
On Sun, Nov 25, 2007 at 07:14:04PM +0100, Thorsten Leemhuis wrote:
audacious
I contacted the fedora packager (who is not very interested in EPEL), because I think it would be nice to have audacious in EPEL. Problem with audacious is that the associated libs are binary incompatible with each releases and upstream is not willing to help with old releases. I am personally not ready to do the backporting work, but somebody else could be interested.
-- Pat
On 25.11.2007 19:24, Patrice Dumas wrote:
On Sun, Nov 25, 2007 at 07:14:04PM +0100, Thorsten Leemhuis wrote:
audacious
I contacted the fedora packager (who is not very interested in EPEL), because I think it would be nice to have audacious in EPEL. Problem with audacious is that the associated libs are binary incompatible with each releases and upstream is not willing to help with old releases. I am personally not ready to do the backporting work, but somebody else could be interested.
Well, the world is not perfect and we have to deal with it somehow without reinventing the weel.
IOW: For exactly this kind of software EPEL allows updates to the latest upstream version in case of major bug fixes or fixes for security related problems. Even updates to newer upstream version to improve the user experience or to make new stuff possible are IMHO acceptable now and then if they are carefully done.
We just don't want to have a Fedora-like "update like cracy" repo -- that is good for Fedora ans its users afaics, but not ideal for a distribution were people pay lot of money for the stable approach.
CU knurd
On Sun, Nov 25, 2007 at 07:43:45PM +0100, Thorsten Leemhuis wrote:
On 25.11.2007 19:24, Patrice Dumas wrote:
On Sun, Nov 25, 2007 at 07:14:04PM +0100, Thorsten Leemhuis wrote:
audacious
I contacted the fedora packager (who is not very interested in EPEL), because I think it would be nice to have audacious in EPEL. Problem with audacious is that the associated libs are binary incompatible with each releases and upstream is not willing to help with old releases. I am personally not ready to do the backporting work, but somebody else could be interested.
Well, the world is not perfect and we have to deal with it somehow without reinventing the weel.
IOW: For exactly this kind of software EPEL allows updates to the latest upstream version in case of major bug fixes or fixes for security related problems. Even updates to newer upstream version to improve the user experience or to make new stuff possible are IMHO acceptable now and then if they are carefully done.
You mean breaking the ABI is allowed? I was under the impression that it was not.
-- Pat
On 25.11.2007 20:35, Patrice Dumas wrote:
On Sun, Nov 25, 2007 at 07:43:45PM +0100, Thorsten Leemhuis wrote:
On 25.11.2007 19:24, Patrice Dumas wrote:
On Sun, Nov 25, 2007 at 07:14:04PM +0100, Thorsten Leemhuis wrote:
audacious
I contacted the fedora packager (who is not very interested in EPEL), because I think it would be nice to have audacious in EPEL. Problem with audacious is that the associated libs are binary incompatible with each releases and upstream is not willing to help with old releases. I am personally not ready to do the backporting work, but somebody else could be interested.
Well, the world is not perfect and we have to deal with it somehow without reinventing the weel. IOW: For exactly this kind of software EPEL allows updates to the latest upstream version in case of major bug fixes or fixes for security related problems. Even updates to newer upstream version to improve the user experience or to make new stuff possible are IMHO acceptable now and then if they are carefully done.
You mean breaking the ABI is allowed?
If there are no other way around that, yes, then it IMHO is allowed, if you make sure other packages that depend on your ABI get updated/rebuild the same time. Ohh, and sending out a "heads up" to users and developers beforehand and when the update actually hits the proper repos as well would be good.
CU knurd
On Mon, Nov 26, 2007 at 06:40:26AM +0100, Thorsten Leemhuis wrote:
If there are no other way around that, yes, then it IMHO is allowed, if you make sure other packages that depend on your ABI get updated/rebuild the same time. Ohh, and sending out a "heads up" to users and developers beforehand and when the update actually hits the proper repos as well would be good.
This seems to be a bit dangerous, in case a new version of the dependent software or library is needed for th enew API. Otherwise said this could lead to a forced update of the other packages that depend on that library. This seems to me to be quite problematic, and not something we should do.
If it happens by chance that we have to break API, then no problem, but if we can forecast, at the time we introduce a library, that there will be some API change, we won't be able to backport critical fixes and it is possible for security issues to happen in the EPEL lifetime, then it is a completly different issue, we are asking for trouble.
-- Pat
On 26.11.2007 09:54, Patrice Dumas wrote:
On Mon, Nov 26, 2007 at 06:40:26AM +0100, Thorsten Leemhuis wrote:
If there are no other way around that, yes, then it IMHO is allowed, if you make sure other packages that depend on your ABI get updated/rebuild the same time. Ohh, and sending out a "heads up" to users and developers beforehand and when the update actually hits the proper repos as well would be good.
This seems to be a bit dangerous, in case a new version of the dependent software or library is needed for th enew API. Otherwise said this could lead to a forced update of the other packages that depend on that library. This seems to me to be quite problematic, and not something we should do.
Sure it's dangerous and problematic -- but it's IMHO still way better then to not ship a package just for hypothetical situation where a major update might be the only way forward if a security issues comes up.
Besides: if we want to update for non-security reasons we can provide compat packages as well, which should solve parts of the problem.
CU knurd
On Mon, Nov 26, 2007 at 05:18:19PM +0100, Thorsten Leemhuis wrote:
Sure it's dangerous and problematic -- but it's IMHO still way better then to not ship a package just for hypothetical situation where a major update might be the only way forward if a security issues comes up.
Besides: if we want to update for non-security reasons we can provide compat packages as well, which should solve parts of the problem.
Ok, but then what to do when a security issue is discovered in the package that is also relevant for the compat package but we don't want to backport it? Simply remove the compat package from the repo?
-- Pat
On 05.12.2007 11:30, Patrice Dumas wrote:
On Mon, Nov 26, 2007 at 05:18:19PM +0100, Thorsten Leemhuis wrote:
Sure it's dangerous and problematic -- but it's IMHO still way better then to not ship a package just for hypothetical situation where a major update might be the only way forward if a security issues comes up. Besides: if we want to update for non-security reasons we can provide compat packages as well, which should solve parts of the problem.
Ok, but then what to do when a security issue is discovered in the package that is also relevant for the compat package but we don't want to backport it? Simply remove the compat package from the repo?
If there was a warning period or something like that, round about: yes.
Note that even RHEL does that iirc. Didn't they for example switch from mozilla to seamonkey?
Cu knurd
On Wed, Dec 05, 2007 at 11:38:01AM +0100, Thorsten Leemhuis wrote:
On 05.12.2007 11:30, Patrice Dumas wrote:
On Mon, Nov 26, 2007 at 05:18:19PM +0100, Thorsten Leemhuis wrote:
Sure it's dangerous and problematic -- but it's IMHO still way better then to not ship a package just for hypothetical situation where a major update might be the only way forward if a security issues comes up. Besides: if we want to update for non-security reasons we can provide compat packages as well, which should solve parts of the problem.
Ok, but then what to do when a security issue is discovered in the package that is also relevant for the compat package but we don't want to backport it? Simply remove the compat package from the repo?
If there was a warning period or something like that, round about: yes.
Note that even RHEL does that iirc. Didn't they for example switch from mozilla to seamonkey?
But this is not exactly the same, since one obsolete the other. So the plan could be along obsoleting th ecompat package with the oldest compat package not having the security flaw? Otherwise the compat package will stay happily even though it isn't anymore in the repo.
-- Pat
On 05.12.2007 16:51, Patrice Dumas wrote:
On Wed, Dec 05, 2007 at 11:38:01AM +0100, Thorsten Leemhuis wrote:
On 05.12.2007 11:30, Patrice Dumas wrote:
On Mon, Nov 26, 2007 at 05:18:19PM +0100, Thorsten Leemhuis wrote:
Sure it's dangerous and problematic -- but it's IMHO still way better then to not ship a package just for hypothetical situation where a major update might be the only way forward if a security issues comes up. Besides: if we want to update for non-security reasons we can provide compat packages as well, which should solve parts of the problem.
Ok, but then what to do when a security issue is discovered in the package that is also relevant for the compat package but we don't want to backport it? Simply remove the compat package from the repo?
If there was a warning period or something like that, round about: yes. Note that even RHEL does that iirc. Didn't they for example switch from mozilla to seamonkey?
But this is not exactly the same, since one obsolete the other.
Well, it was the same software in a newer version that also gotten a new name.
So the plan could be along obsoleting th ecompat package with the oldest compat package not having the security flaw? Otherwise the compat package will stay happily even though it isn't anymore in the repo.
Yeah, that could work.
But I think we just need to find individual solutions for problems when we hit them.
CU knurd
On Wed, Dec 05, 2007 at 05:32:01PM +0100, Thorsten Leemhuis wrote:
So the plan could be along obsoleting th ecompat package with the oldest compat package not having the security flaw? Otherwise the compat package will stay happily even though it isn't anymore in the repo.
Yeah, that could work.
But I think we just need to find individual solutions for problems when we hit them.
We need a little bit if planification too. If we bring a package in and we find out that we cannot technicaly make the user notice that there is something wrong with the package, it is a problem and we must take it into account right now.
-- Pat
On 05.12.2007 17:51, Patrice Dumas wrote:
On Wed, Dec 05, 2007 at 05:32:01PM +0100, Thorsten Leemhuis wrote:
So the plan could be along obsoleting th ecompat package with the oldest compat package not having the security flaw? Otherwise the compat package will stay happily even though it isn't anymore in the repo.
Yeah, that could work. But I think we just need to find individual solutions for problems when we hit them.
We need a little bit if planification too.
Yes, completely agreed. But I'd like to avoid a deadlock where packages do not enter the repo because people fear hypothetical problems. We'll find solutions when problem comes up (just as RH sometimes has to find special solutions). And nobody pays us for the job, so I suspect most people won't yell at us when we say "okay, we had to update foo to version bar which break ABI and API because backporting the security fix was to hard"
CU knurd
On Wed, Dec 05, 2007 at 07:34:11PM +0100, Thorsten Leemhuis wrote:
Yes, completely agreed. But I'd like to avoid a deadlock where packages do not enter the repo because people fear hypothetical problems. We'll find solutions when problem comes up (just as RH sometimes has to find special solutions).
I am not completly convinced, shouldn't the solution be found in fedora rather than in EPEL?
And nobody pays us for the job, so I suspect most people won't yell at us when we say "okay, we had to update foo to version bar which break ABI and API because backporting the security fix was to hard"
It is not the point, in my opinion. The point is if we can be almost sure that a package will bring in some problems we want to avoid, then we should avoid it. What is unclear to me is what we want to avoid.
-- Pat
epel-devel@lists.fedoraproject.org
-
Karsten Wade -
Michael Stahnke -
Patrice Dumas -
Thorsten Leemhuis