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
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
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
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
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
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
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
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
On 8/16/07, Rahul Sundaram sundaram@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@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
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.
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
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
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@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
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
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
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.
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
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
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
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
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
epel-devel@lists.fedoraproject.org
-
Jon Ciesla -
Karsten Wade -
Michael DeHaan -
Michael Stahnke -
Mike McGrath -
Patrice Dumas -
Rahul Sundaram -
Ray Van Dolson -
Thorsten Leemhuis