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

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list