12:32 p.m.
Hi all, so the (only) package I maintain, remind, has released a new
version (from 3.0.24 to 3.1.0). There are some new features and some
bug fixes:
http://www.bludgeon.org/~rayvd/WHATSNEW
However, per the update guidelines and policies, it doesn't appear to
meet the criteria as an update that should be pushed (although maybe to
the 5.1 and 4.6 releases) -- none of the bug fixes are "critical"
really.
That said, from observing the build reports, it seems as if a lot of
people are pushing new upstream releases of their packages into the
current version of EPEL (updates, not the new builds). It doesn't seem
that all of these updates are in harmony with the update policies.
I realize that probably very few will care if I end up pushing my
update to 4.5 and 5.0, and nothing will break; but is this the right
thing to do?
Thanks for the clarification,
Ray
12:50 p.m.
On Wed, 2007-08-15 at 10:32 -0700, Ray Van Dolson wrote:
That said, from observing the build reports, it seems as if a lot of
people are pushing new upstream releases of their packages into the
current version of EPEL (updates, not the new builds). It doesn't seem
that all of these updates are in harmony with the update policies.
I realize that probably very few will care if I end up pushing my
update to 4.5 and 5.0, and nothing will break; but is this the right
thing to do?
I don't know the answer for sure, but I think you are asking the right
question. I haven't been watching the builds for enforcement. Do we
need to do that? Are we going to be constantly reminding people not to
wantonly update in EPEL?
We need to resolve this before we suddenly have a broken, sodden mess
due to people following this policy differently.
- Karsten
--
Karsten Wade ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.fedorapeople.org | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
12:51 p.m.
On 15.08.2007 19:32, Ray Van Dolson wrote:
Hi all, so the (only) package I maintain, remind, has released a new
version (from 3.0.24 to 3.1.0). There are some new features and some
bug fixes:
http://www.bludgeon.org/~rayvd/WHATSNEW
However, per the update guidelines and policies, it doesn't appear to
meet the criteria as an update that should be pushed (although maybe to
the 5.1 and 4.6 releases) -- none of the bug fixes are "critical"
really.
From this description I'd say: don't update.
That said, from observing the build reports, it seems as if a lot of
people are pushing new upstream releases of their packages into the
current version of EPEL (updates, not the new builds). It doesn't seem
that all of these updates are in harmony with the update policies.
I noticed that also and put a "poke those people and point them to the
EPEL update guidelines" on my todo-list.
The current behavior might be acceptable for the current phase where
EPEL is still young, but if people really want a repo that ships more
up2date packages I'd say we start EPEL-rolling in parallel with
EPEL-stable (e.g. a repo on top of epel-stable).
A repo where some packages stay stable while others are updated to the
latest and greatest is a mix that won't make people happy, as those that
are those that are interested in a "a stable base" and those that want
"latest and greatest" both don't get what they want.
IOW: we should pick a side (and we did), as something in between is bad.
[...]
Cu
thl
3:39 a.m.
Thorsten Leemhuis wrote:
A repo where some packages stay stable while others are updated to
the
latest and greatest is a mix that won't make people happy, as those that
are those that are interested in a "a stable base" and those that want
"latest and greatest" both don't get what they want.
On the other hand this is what happens within the base product too. The
desktop apps and treated different from system apps for example. You
might want to consider having a policy that differentiates between them.
Rahul
4:02 a.m.
On 16.08.2007 10:39, Rahul Sundaram wrote:
Thorsten Leemhuis wrote:
> A repo where some packages stay stable while others are updated to the
> latest and greatest is a mix that won't make people happy, as those that
> are those that are interested in a "a stable base" and those that want
> "latest and greatest" both don't get what they want.
On the other hand this is what happens within the base product too. The
desktop apps and treated different from system apps for example.
Could you or somebody else outline the scheme RHEL uses in more detail?
Is it anywhere written down?
You
might want to consider having a policy that differentiates between them.
AFAICS the current RHEL-scheme is similar to what the EPEL policy says
already: If there are very strong reason to update something to a new
major version then go for it with the next quarterly update. But the
bulk of packages doesn't get updates to the latest major version.
Further: I don't think a more detailed "policy" makes sense -- I'd say
we should discuss all "major update: yes or no?" for EPEL on a case by
case basis here on the list. In RHEL I suppose it's similar: a
release-engineer (or whatever the individual or group is called) likely
has to ACK major updates there as well.
CU
knurd
7:06 a.m.
Thorsten Leemhuis wrote:
On 16.08.2007 10:39, Rahul Sundaram wrote:
> Thorsten Leemhuis wrote:
>
>> A repo where some packages stay stable while others are updated to the
>> latest and greatest is a mix that won't make people happy, as those that
>> are those that are interested in a "a stable base" and those that want
>> "latest and greatest" both don't get what they want.
> On the other hand this is what happens within the base product too. The
> desktop apps and treated different from system apps for example.
Could you or somebody else outline the scheme RHEL uses in more detail?
Is it anywhere written down?
Not anywhere publicly afaik but I don't think a lot of it would apply to
EPEL anyway as we cannot expect EPEL maintainers to be doing a lot of
backporting.
If I maintain a package which is written in a language or code I am not
very familiar with and it has a critical security along with other major
changes, I am going to pull in all of that and fix the issue anyway.
The general idea is that the risk of breakage in a core component or
library is large and the benefit is small when compared to desktop or
leaf applications so be more conservative in the former and slightly
more liberal in the latter.
Further: I don't think a more detailed "policy" makes
sense -- I'd say
we should discuss all "major update: yes or no?" for EPEL on a case by
case basis here on the list. In RHEL I suppose it's similar: a
release-engineer (or whatever the individual or group is called) likely
has to ACK major updates there as well.
RHEL follows a model which involves engineers, product management (which
depends on customer input) and QA and depending on the package, the
individual backported patches has to be reviewed with multiple engineers
other than the person doing the work. Obviously this requires resources
we don't have in EPEL.
Maintainers should probably be trusted to make the best judgments in
EPEL keeping in mind that less churn is more desirable. If you aren't
sure, don't update.
Rahul
7:39 a.m.
On 16.08.2007 14:06, Rahul Sundaram wrote:
Thorsten Leemhuis wrote:
> On 16.08.2007 10:39, Rahul Sundaram wrote:
>> Thorsten Leemhuis wrote:
>>
>>> A repo where some packages stay stable while others are updated to the
>>> latest and greatest is a mix that won't make people happy, as those that
>>> are those that are interested in a "a stable base" and those that
want
>>> "latest and greatest" both don't get what they want.
>> On the other hand this is what happens within the base product too. The
>> desktop apps and treated different from system apps for example.
> Could you or somebody else outline the scheme RHEL uses in more detail?
> Is it anywhere written down?
Not anywhere publicly afaik but I don't think a lot of it would apply to
EPEL anyway as we cannot expect EPEL maintainers to be doing a lot of
backporting.
"update to latest version instead of backporting" is allowed by the EPEL
policy to fix a important bug. But the mail that started this thread
wasn't about fixing a important bug.
But we drift away.
[...]
> Further: I don't think a more detailed "policy" makes sense -- I'd
say
> we should discuss all "major update: yes or no?" for EPEL on a case by
> case basis here on the list. In RHEL I suppose it's similar: a
> release-engineer (or whatever the individual or group is called) likely
> has to ACK major updates there as well.
RHEL follows a model which involves engineers, product management (which
depends on customer input) and QA and depending on the package, the
individual backported patches has to be reviewed with multiple engineers
other than the person doing the work. Obviously this requires resources
we don't have in EPEL.
Sure. But we have a mailing list and sending a "what do you guys think:
should I update from foo-x.y to foo-x.(y+1) or foo-(x+1).0 because bar"
is not that much overhead IMHO.
Maintainers should probably be trusted to make the best judgments in
EPEL keeping in mind that less churn is more desirable. [...]
I'd like to agree, but seems at least some people simply build new stuff
for EPEL and don't care (or don't know) about the "only update to new
version if there is a strong need to" policy which EPEL has. So we
sooner or later need tell those maintainers to be more careful, adjust
our policy/goals, start EPEL-rolling in parallel, <insert other
possibilities> or live with the fact that parts of the EPEL-stable repo
follow the a rolling-release scheme similar to Fedora while other parts
go for the careful RHEL-style. The latter would IMHO be quite bad, and I
really don#t want us to go in that direction.
CU
knurd
7:47 a.m.
Thorsten Leemhuis wrote:
Sure. But we have a mailing list and sending a "what do you guys think:
should I update from foo-x.y to foo-x.(y+1) or foo-(x+1).0 because bar"
is not that much overhead IMHO.
Yes but in many cases the people most qualified to make that
determination are those maintaining the packages. If you want to
explicitly document that maintainers have the choice to ask in this
list, that would be a good thing to do.
I'd like to agree, but seems at least some people simply build new stuff
for EPEL and don't care (or don't know) about the "only update to new
version if there is a strong need to" policy which EPEL has. So we
sooner or later need tell those maintainers to be more careful, adjust
our policy/goals, start EPEL-rolling in parallel, <insert other
possibilities> or live with the fact that parts of the EPEL-stable repo
follow the a rolling-release scheme similar to Fedora while other parts
go for the careful RHEL-style. The latter would IMHO be quite bad, and I
really don#t want us to go in that direction.
Watch changes. If you see maintainers pushing updates where it isn't
required then engage them in a private discussion. Maybe they have
reasons to update which wasn't obvious. Maybe there wasn't aware of the
policy or thought that this particular instance needed a exception for
valid reasons. Lets see if there are problems to be solved before
attempting to solve any.
Rahul
8:46 a.m.
On 8/16/07, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Thorsten Leemhuis wrote:
>
> Sure. But we have a mailing list and sending a "what do you guys think:
> should I update from foo-x.y to foo-x.(y+1) or foo-(x+1).0 because bar"
> is not that much overhead IMHO.
Yes but in many cases the people most qualified to make that
determination are those maintaining the packages. If you want to
explicitly document that maintainers have the choice to ask in this
list, that would be a good thing to do.
>
> I'd like to agree, but seems at least some people simply build new stuff
> for EPEL and don't care (or don't know) about the "only update to new
> version if there is a strong need to" policy which EPEL has. So we
> sooner or later need tell those maintainers to be more careful, adjust
> our policy/goals, start EPEL-rolling in parallel, <insert other
> possibilities> or live with the fact that parts of the EPEL-stable repo
> follow the a rolling-release scheme similar to Fedora while other parts
> go for the careful RHEL-style. The latter would IMHO be quite bad, and I
> really don#t want us to go in that direction.
Watch changes. If you see maintainers pushing updates where it isn't
required then engage them in a private discussion. Maybe they have
reasons to update which wasn't obvious. Maybe there wasn't aware of the
policy or thought that this particular instance needed a exception for
valid reasons. Lets see if there are problems to be solved before
attempting to solve any.
Rahul
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
I am enjoying this discussion. Both sides have very good points. As
for my opinion, I think that new packages can go to stable (assuming
deps are there) and updates, can sit until major update. I am sure
this has flaws, (deps in particular). I feel that EPEL isn't too
usable yet for an EL customer. There just are not enough packges. I
don't think we should have more barriers to get packages in. I know
customer could enable testing, but if they felt ok enabling testing,
they probably wouldn't be running on RHEL/EL. I understand what
EPEL/Fedora testing means, customers hear testing and stay away.
stahnma
11:09 a.m.
On 17.08.2007 15:46, Michael Stahnke wrote:
[...]
I am enjoying this discussion. Both sides have very good points. As
for my opinion, I think that new packages
We more and more discuss two different things in this thread: "to update
a existing package" and "ship new packages in stable directly"
can go to stable (assuming deps are there)
I'd be fine with this, as long as they have been in testing for a while
(some weeks maybe) -- I consider "testing" a kind of beta-stage, that
allows packers as well as others interested in EPEL to test the software
before it hits the proper repo.
I really think such a timeperiod is needed to make sure packagers are
actually working.
and updates, can sit until major update. I am sure
this has flaws, (deps in particular).
Well, if someone volunteers to find a way (script, manually, ...) to
push new packages that were in testing for a while from testing to
stable while making sure all deps are still satisfied I'd say: go for it.
I feel that EPEL isn't too
usable yet for an EL customer. There just are not enough packges. I
don't think we should have more barriers to get packages in. I know
customer could enable testing, but if they felt ok enabling testing,
they probably wouldn't be running on RHEL/EL. I understand what
EPEL/Fedora testing means, customers hear testing and stay away.
At the same time it's IMHO especially for EPEL very important to ship
quality right from the start, as we are currently still "building the
new brand 'EPEL'" phase. The view and impression others get about (¹) us
now and in hte next months will be our fame for the next years.
CU
knurd
(¹) -- s/about/on/ ? Sorry, seems I always get this wrong.
11:18 a.m.
Thorsten Leemhuis wrote:
On 17.08.2007 15:46, Michael Stahnke wrote:
> [...]
> I am enjoying this discussion. Both sides have very good points. As
> for my opinion, I think that new packages
>
We more and more discuss two different things in this thread: "to update
a existing package" and "ship new packages in stable directly"
> can go to stable (assuming deps are there)
>
I'd be fine with this, as long as they have been in testing for a while
(some weeks maybe) -- I consider "testing" a kind of beta-stage, that
allows packers as well as others interested in EPEL to test the software
before it hits the proper repo.
What we're really talking about here is QA. Leaving things in testing
is sort of an automated way of doing QA. We call it "testing" and
people know it might not work, they don't have any expectation that it
will work. At the same time, hopefully, people are using the package
and reporting bugs.
Implementing an actual QA process is very difficult and requires a lot
of commitment. And, unfortunately, shipping straight from build and
high quality "enterprise" stuff (even if its new packages) are just
conflicting ideas. Though I agree, leaving packages in testing might
deter new contributors. Its a tricky situation.
-Mike
1:49 p.m.
I'm in favor of having enabling a more frequent update process
for those
who choose it. Right now, that seems to be "testing" but it's not. As
implemented "testing"
can be a mix of very new untested packages and some that are probably in
great shape.
When an admin adds "testing" as a repo, he gets the possibility for both.
Debian has solved this.
This is why Debian has the multi-level system:
experimental -- I just updated this package, it may eat your brane
unstable -- I think this will work, it's been in experimental for __X__
unit time without problems
testing -- I confidentially stand behind this package, it's been in
unstable for __Y__ unit time without problems
stable -- really really stable
Please ignore the Debian release schedule. The process works very well
for users, regardless of what "X" and "Y" are. As the
community size increases, I imagine "X" and "Y" can be made smaller.
Users get to pick how much they want to live on the edge. I can
confidentally run "testing" at home knowing very little (if anything)
will ever break. I can probably even run "unstable" and be pretty safe.
So, what we are currently doing is treating EPEL's "testing" as Debian
experimental and EPEL's "stable" as "stable".
What I would propose is the following compromise:
experimental --- all new updates go here
testing -- pushable if no defects in experimental for 2 weeks
stable -- pushed quarterly
We can basically do most of this with bohdi now.
Later, we can add the requirement that a package needs either "X" weeks
in experimental or so many people vouching
for it to go in stable. Or whatever.
The point is -- folks run RHEL for a stable base. But it is not just a
boxed product. It's a platform. People should be able to
choose what they do with it, and not be stuck running old&stale EPEL
packages if they want some assurance of stability, however
minimal.
This doesn't need a QA team to implement -- it just requires one extra
level in bohdi, and a bit of practice around it.
+1. In the current world, how do we get a package out of testing? I know
I still have one with a broken dep, but once that's fixed. ..
--Michael DeHaan
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
novus ordo absurdum
2:03 p.m.
I'm in favor of having enabling a more frequent update process for those
who choose it. Right now, that seems to be "testing" but it's not. As
implemented "testing"
can be a mix of very new untested packages and some that are probably in
great shape.
When an admin adds "testing" as a repo, he gets the possibility for both.
Debian has solved this.
This is why Debian has the multi-level system:
experimental -- I just updated this package, it may eat your brane
unstable -- I think this will work, it's been in experimental for __X__
unit time without problems
testing -- I confidentially stand behind this package, it's been in
unstable for __Y__ unit time without problems
stable -- really really stable
Please ignore the Debian release schedule. The process works very well
for users, regardless of what "X" and "Y" are. As the
community size increases, I imagine "X" and "Y" can be made smaller.
Users get to pick how much they want to live on the edge. I can
confidentally run "testing" at home knowing very little (if anything)
will ever break. I can probably even run "unstable" and be pretty safe.
So, what we are currently doing is treating EPEL's "testing" as Debian
experimental and EPEL's "stable" as "stable".
What I would propose is the following compromise:
experimental --- all new updates go here
testing -- pushable if no defects in experimental for 2 weeks
stable -- pushed quarterly
We can basically do most of this with bohdi now.
Later, we can add the requirement that a package needs either "X" weeks
in experimental or so many people vouching
for it to go in stable. Or whatever.
The point is -- folks run RHEL for a stable base. But it is not just a
boxed product. It's a platform. People should be able to
choose what they do with it, and not be stuck running old&stale EPEL
packages if they want some assurance of stability, however
minimal.
This doesn't need a QA team to implement -- it just requires one extra
level in bohdi, and a bit of practice around it.
--Michael DeHaan
2:14 p.m.
The point is -- folks run RHEL for a stable base. But it is not just
a boxed
product. It's a platform. People should be able to
choose what they do with it, and not be stuck running old&stale EPEL
packages if they want some assurance of stability, however
minimal.
From a user standpoint, I think this is very true. I like the
stability of RHEL, but sometimes I do end up wanting a feature of a
recently updated upstream project, and either have to rebuild an SRPM
from Fedora, go to another repo or build from source.
Also, in my case with remind, it's not a library with an ABI that
people are linking against that might break, it's just an application.
I suppose a change in the feature-set could break remind scripts
however.
But having the option at least, and from a trustworthy source like
EPEL, to track somewhat-latest versions of packages of our choosing
would be nice.
But maybe it makes for too much of a grey area?
Ray
6:51 a.m.
Hi!
On 17.08.2007 20:49, Jon Ciesla wrote:
[...]
> Debian has solved this.
>
> This is why Debian has the multi-level system:
We IMHO have a multi-level-system as well if you look at the big
picture. It's similar, but not exactly the same
> experimental -- I just updated this package, it may eat your
brane
Fedora rawhide.
> unstable -- I think this will work, it's been in experimental
for __X__
> unit time without problems
Fedora test releases .
> testing -- I confidentially stand behind this package, it's
been in
> unstable for __Y__ unit time without problems
> stable -- really really stable
here we are more different. we have
- stable Fedora releases (Core + Extras in the past), which gets update
that come from testing, but not supporterd for longer time-periods
- stable RHEL releases + stable EPEL releases; new RHEL releases (5.1,
...) get tested in Betas (RHEL 5.1 Beta is out now); new EPEL packages
get tested in testing
[...]
> So, what we are currently doing is treating EPEL's "testing" as Debian
> experimental and EPEL's "stable" as "stable".
Nope -- experimental is Fedora rawhide, Fedora release, where stuff that
hits EPEL should get tested and shipped first. EPEL-testing is a kind of
beta-phase before things that were tested in Fedora hit EPEL stable.
> What I would propose is the following compromise:
>
> experimental --- all new updates go here
> testing -- pushable if no defects in experimental for 2 weeks
> stable -- pushed quarterly
I think it's to much overhead for a small gain. We have bigger problems
to solve first IMHO.
> We can basically do most of this with bohdi now.
Which we can't use without koji, which needs to be modifies before we
can use it.
[...]
+1. In the current world, how do we get a package out of testing? I know
I still have one with a broken dep, but once that's fixed. ..
It's written in the guidelines. New packages get into the repo with a
quarterly update -- just as RHEL does it in RHEL updates now and then. I
multiple times asked in the past to do it a bit more often (e.g. every
two months maybe), but that's still under discussion.
CU
knurd
7:04 a.m.
On 17.08.2007 21:14, Ray Van Dolson wrote:
> The point is -- folks run RHEL for a stable base. But it is not
just a boxed
> product. It's a platform. People should be able to
> choose what they do with it, and not be stuck running old&stale EPEL
> packages if they want some assurance of stability, however
> minimal.
>From a user standpoint, I think this is very true. I like the
stability of RHEL, but sometimes I do end up wanting a feature of a
recently updated upstream project, and either have to rebuild an SRPM
from Fedora, go to another repo or build from source.
The main problem IMHO is: what part of the "stable base" for user foo
might be the package where user bar "wants a feature of a recently
updated upstream project". There is no way with current tools to serve
both users in one repo.
But we could do it in two repos -- one stable EPEL repo and a "EPEL
rolling" on top of it -- then users could individually select which
software they want in newer versions.
I think that's exactly what we should do in the long term, but I don't
think we have the man-power yet to maintain both repos, so we
concentrate on the EPEL stable stuff atm, as that's IMHO more important
stuff users of RHEL or use CentOS want and are used to.
Cu
knurd
10:09 a.m.
But we could do it in two repos -- one stable EPEL repo and a
"EPEL
rolling" on top of it -- then users could individually select which
software they want in newer versions.
If I want a rolling upstream, why am I using EL? You use a EL to
avoid quick releases and be on supported ABI compatible versions of
X,Y,Z for long periods of time. The notable exceptions are things
like a LAMP stack, but RH provides subscriptions and updates to that
more frequently on EL.
A rolling repo should just be a symlink to Fedora. That's why Fedora exists.
stahnma
10:19 a.m.
On Sat, Aug 18, 2007 at 10:09:10AM -0500, Michael Stahnke wrote:
> But we could do it in two repos -- one stable EPEL repo and a
"EPEL
> rolling" on top of it -- then users could individually select which
> software they want in newer versions.
If I want a rolling upstream, why am I using EL? You use a EL to
avoid quick releases and be on supported ABI compatible versions of
X,Y,Z for long periods of time. The notable exceptions are things
like a LAMP stack, but RH provides subscriptions and updates to that
more frequently on EL.
We cannot rely on RH for packages in EPEL that have are similar with
LAMP stack with respect with updating.
A rolling repo should just be a symlink to Fedora. That's why
Fedora exists.
Not exaclty. It would maybe share some similarities with fedora but
without a need to upgrade the base os. That's completly different. It
isn't clear to me that it is very usefull, though, but it certainly adds
something.
And also you may also want to keep ABI compatibility while still updating
more rapidly some parts, the desktop for example.
--
Pat
10:33 a.m.
On 18.08.2007 17:09, Michael Stahnke wrote:
> But we could do it in two repos -- one stable EPEL repo and a
"EPEL
> rolling" on top of it -- then users could individually select which
> software they want in newer versions.
If I want a rolling upstream, why am I using EL? You use a EL to
avoid quick releases and be on supported ABI compatible versions of
X,Y,Z for long periods of time. The notable exceptions are things
like a LAMP stack, but RH provides subscriptions and updates to that
more frequently on EL.
A rolling repo should just be a symlink to Fedora. That's why Fedora exists.
I'd mostly agree and that's why I don't think a rolling repo should be
high on our todo-list.
Nevertheless it seems people often are in the need to have a stable base
with "newer version of foo and bar" on it. But everyone needs different
"foo and bars" (and thus also defines the packageset of the stable base
differently).
I imagine a EPEL rolling add-one repo (on top of stable EPEL) together
with a yum-plugin where people can configure to get "foo and bar" from
EPEL rolling could serve those users.
But that's atm nothing more then "dreaming how a solution for those
users could look like".
CU
thl
7:47 a.m.
On 20.08.2007 14:33, Michael DeHaan wrote:
Thorsten Leemhuis wrote:
>
>>> experimental -- I just updated this package, it may eat your brane
> Fedora rawhide.
Rawhide packages installing on RHEL? Surely not.
From the part you stripped in your reply: "We IMHO have a
multi-level-system as well if you look at the big picture."
Big picture = "Fedora and RHEL as a whole"
rawhide is indirectly the experimental for RHEL as well as for EPEL.
CU
knurd
7:57 a.m.
Thorsten Leemhuis wrote:
Big picture = "Fedora and RHEL as a whole"
rawhide is indirectly the experimental for RHEL as well as for EPEL.
Obviously, I know this -- the point is we aren't trying to create a way
to build a distribution here, and this is where I believe the mistake lies.
EPEL is a gateway to provide additional packages to a distribution which
is, of course, emergent from the aforementioned rawhide/Fedora/etc.
What I want to see here is a way for SA's to find packages that help
them get their job done, without going through lots of pain with
rpmbuild and finding
missing deps. This means making a certain quality of packages
available, but it should not restrict SA's to old content. "Old" isn't
the same as stable, we
need other critera for that, or just to have the ability for someone to
manually push to testing to stable -- and just put some basic
recommendations around
that.
6096
days inactive
6101
days old
epel-devel@lists.fedoraproject.org
21 comments
9 participants
participants (9)
-
Jon Ciesla -
Karsten Wade -
Michael DeHaan -
Michael Stahnke -
Mike McGrath -
Patrice Dumas -
Rahul Sundaram -
Ray Van Dolson -
Thorsten Leemhuis