What hoops do I have to jump through, approvals, etc., do I need to respin glusterfs rpms as glusterfs32 (for 3.2.6, and soon 3.2.7), and the imminent glusterfs-3.3.0, which would be glusterfs33.
I.e. what is currently glusterfs-3.2.6-2.{fc16,fc17,el6} would become glusterfs32-3.2.6-x.{fc16,fc17,el6}, etc. x would be what, 1? 2? Does it matter?
And of course then respin HekaFS rpms with the dependency changed to the new name.
This would serve two purposes: a) resolves the glusterfs in EPEL and RHS Channel debate, b) lets us ship glusterfs33 in f16, f17, and f18 along with glusterfs32+HekaFS, since we don't (currently) plan to update HekaFS for glusterfs33. HekaFS features will be added to later releases of glusterfs33.
Any hoops? Or can I just go ahead and do this?
On 05/30/2012 11:46 AM, Kaleb S. KEITHLEY wrote:
What hoops do I have to jump through, approvals, etc., do I need to respin glusterfs rpms as glusterfs32 (for 3.2.6, and soon 3.2.7), and the imminent glusterfs-3.3.0, which would be glusterfs33.
I.e. what is currently glusterfs-3.2.6-2.{fc16,fc17,el6} would become glusterfs32-3.2.6-x.{fc16,fc17,el6}, etc. x would be what, 1? 2? Does it matter?
And of course then respin HekaFS rpms with the dependency changed to the new name.
This would serve two purposes: a) resolves the glusterfs in EPEL and RHS Channel debate, b) lets us ship glusterfs33 in f16, f17, and f18 along with glusterfs32+HekaFS, since we don't (currently) plan to update HekaFS for glusterfs33. HekaFS features will be added to later releases of glusterfs33.
Any hoops? Or can I just go ahead and do this?
Do you really need both? Or could you just update to 33 in the modern targets (F16+) and leave the older 3.2 bits in the not-so-modern target (EL6)?
In general, Fedora prefers not to carry multiple versions of components because it deters and delays usage of the newer version.
~tom
== Fedora Project
On Wed, May 30, 2012 at 11:46:46AM -0400, Kaleb S. KEITHLEY wrote:
What hoops do I have to jump through, approvals, etc., do I need to respin glusterfs rpms as glusterfs32 (for 3.2.6, and soon 3.2.7), and the imminent glusterfs-3.3.0, which would be glusterfs33.
I.e. what is currently glusterfs-3.2.6-2.{fc16,fc17,el6} would become glusterfs32-3.2.6-x.{fc16,fc17,el6}, etc. x would be what, 1? 2? Does it matter?
And of course then respin HekaFS rpms with the dependency changed to the new name.
This would serve two purposes: a) resolves the glusterfs in EPEL and RHS Channel debate, b) lets us ship glusterfs33 in f16, f17, and f18 along with glusterfs32+HekaFS, since we don't (currently) plan to update HekaFS for glusterfs33. HekaFS features will be added to later releases of glusterfs33.
Any hoops? Or can I just go ahead and do this?
This is done for unison:
https://admin.fedoraproject.org/pkgdb/acls/list/unison*
because different versions of unison use a different protocol, and there is a user case where they want to talk to multiple remote machines all using different protocols (and there isn't an easier way of doing it without a massive rewrite upstream that no one has the energy for).
We had to go through a full package review for each name.
To be honest it's a pain in the neck to deal with such packages, and unless there's an overwhelming need, I can't recommend it. Does any user really need to parallel install both versions of glusterfs?
Rich.
On 05/30/2012 12:44 PM, Richard W.M. Jones wrote:
To be honest it's a pain in the neck to deal with such packages, and unless there's an overwhelming need, I can't recommend it. Does any user really need to parallel install both versions of glusterfs?
No, and in fact that would not work. (And it's not the problem we're trying to solve.)
If glusterfs-3.2.x + HekaFS is installed, we essentially want to avoid ever updating to glusterfs-3.3.x because HekaFS is not compatible with it.
One way I can solve this is to never ship glusterfs-3.3.x on f16 and f17 (and EPEL el6).
I'd be perfectly happy saying we will never ship glusterfs-3.3.x on f16 and f17, but the reality is that there probably are people who want it.
Along the same lines, I'd be happy saying we will not ship HekaFS in f18 once glusterfs-3.3.x is out, but there are probably people who want glusterfs-3.2.x, with or without HekaFS.
And FWIW, doing nothing doesn't resolve the glusterfs in EPEL versus glusterfs in the RHS Channel issue.
On 05/30/2012 01:08 PM, Kaleb S. KEITHLEY wrote:
On 05/30/2012 12:44 PM, Richard W.M. Jones wrote:
To be honest it's a pain in the neck to deal with such packages, and unless there's an overwhelming need, I can't recommend it. Does any user really need to parallel install both versions of glusterfs?
No, and in fact that would not work. (And it's not the problem we're trying to solve.)
If glusterfs-3.2.x + HekaFS is installed, we essentially want to avoid ever updating to glusterfs-3.3.x because HekaFS is not compatible with it.
And HekaFS aside, I could also make the case that we don't want people to blindly update from glusterfs-3.2.x to glusterfs-3.3.x.
Another option I'd be willing to consider is leaving glusterfs-3.2.x alone, i.e., as glusterfs-3.2.x-y.fc16, but release glusterfs-3.3.x as glusterfs33, i.e. glusterfs33-3.3.x-1.fc16.
On Wed, May 30, 2012 at 01:23:42PM -0400, Kaleb S. KEITHLEY wrote:
On 05/30/2012 01:08 PM, Kaleb S. KEITHLEY wrote:
On 05/30/2012 12:44 PM, Richard W.M. Jones wrote:
To be honest it's a pain in the neck to deal with such packages, and unless there's an overwhelming need, I can't recommend it. Does any user really need to parallel install both versions of glusterfs?
No, and in fact that would not work. (And it's not the problem we're trying to solve.)
If glusterfs-3.2.x + HekaFS is installed, we essentially want to avoid ever updating to glusterfs-3.3.x because HekaFS is not compatible with it.
And HekaFS aside, I could also make the case that we don't want people to blindly update from glusterfs-3.2.x to glusterfs-3.3.x.
Another option I'd be willing to consider is leaving glusterfs-3.2.x alone, i.e., as glusterfs-3.2.x-y.fc16, but release glusterfs-3.3.x as glusterfs33, i.e. glusterfs33-3.3.x-1.fc16.
Not knowing anything about HekaFS and its relationship to gluster-3.3, it sounds like something that should be handled upstream, ie:
https://fedoraproject.org/wiki/Staying_close_to_upstream_projects
Why wouldn't it work with glusterfs 3.3? Just a matter of development needing to be done, or is there some irreconcilable conflict?
Rich.
On Wed, May 30, 2012 at 6:08 PM, Kaleb S. KEITHLEY kkeithle@redhat.com wrote:
On 05/30/2012 12:44 PM, Richard W.M. Jones wrote:
To be honest it's a pain in the neck to deal with such packages, and unless there's an overwhelming need, I can't recommend it. Does any user really need to parallel install both versions of glusterfs?
No, and in fact that would not work. (And it's not the problem we're trying to solve.)
If glusterfs-3.2.x + HekaFS is installed, we essentially want to avoid ever updating to glusterfs-3.3.x because HekaFS is not compatible with it.
One way I can solve this is to never ship glusterfs-3.3.x on f16 and f17 (and EPEL el6).
That works as it's generally recognised that there shouldn't be major version upgrades and breakages within a release especially one that breaks things.
I'd be perfectly happy saying we will never ship glusterfs-3.3.x on f16 and f17, but the reality is that there probably are people who want it.
So you can always do a fedorapeople repository for those that want to experiment.
Along the same lines, I'd be happy saying we will not ship HekaFS in f18 once glusterfs-3.3.x is out, but there are probably people who want glusterfs-3.2.x, with or without HekaFS.
Those people are then free to stick with Fedora 16, Fedora 17 or EL6.
And FWIW, doing nothing doesn't resolve the glusterfs in EPEL versus glusterfs in the RHS Channel issue.
That's a different story entirely, and why would you want gluster in EPEL when it's already in RHEL? What's the difference?
Peter
On Wed, May 30, 2012 at 11:25 AM, Peter Robinson pbrobinson@gmail.com wrote:
I'd be perfectly happy saying we will never ship glusterfs-3.3.x on f16 and f17, but the reality is that there probably are people who want it.
So you can always do a fedorapeople repository for those that want to experiment.
I second the fedorapeople.org idea. There will always be eager early adopters, and you can cater to them without the bureaucracy of a full package review for something that will naturally go through Rawhide anyways. This seems to have worked well for Kevin's efforts with Xfce 4.10.
- Ken
On 05/30/2012 01:25 PM, Peter Robinson wrote:
And FWIW, doing nothing doesn't resolve the glusterfs in EPEL versus glusterfs in the RHS Channel issue.
That's a different story entirely, and why would you want gluster in EPEL when it's already in RHEL? What's the difference?
This has been beaten to death already. It's not in RHEL. It's in the RHS Channel for RHSA. Some client-side bits will eventually be released in RHEL7.
And there are more users of EPEL than just RHEL.
And since it's already in EPEL, and has been for a couple of years, as glusterfs I'd say the burden is on the RHEL packagers to pick a name that doesn't conflict with what's in EPEL. Unless the name gets changed before then.
On 05/30/2012 01:34 PM, Kaleb S. KEITHLEY wrote:
On 05/30/2012 01:25 PM, Peter Robinson wrote:
And FWIW, doing nothing doesn't resolve the glusterfs in EPEL versus glusterfs in the RHS Channel issue.
That's a different story entirely, and why would you want gluster in EPEL when it's already in RHEL? What's the difference?
This has been beaten to death already. It's not in RHEL. It's in the RHS Channel for RHSA. Some client-side bits will eventually be released in RHEL7.
Just to be clear, it's been extensively discussed on an epel list @redhat. Sorry for for the omission.
As for the RHS Channel and RHSA, suffice it to say, it's not RHEL. That's the key point.
There seems to be some small consensus that not shipping glusterfs-3.3.x on f16 and f17 is the correct strategy, and I'm happy with that. And if everyone else is happy with that then no rename is necessary.
On Wed, May 30, 2012 at 7:11 PM, Kaleb S. KEITHLEY kkeithle@redhat.com wrote:
On 05/30/2012 01:34 PM, Kaleb S. KEITHLEY wrote:
On 05/30/2012 01:25 PM, Peter Robinson wrote:
And FWIW, doing nothing doesn't resolve the glusterfs in EPEL versus glusterfs in the RHS Channel issue.
That's a different story entirely, and why would you want gluster in EPEL when it's already in RHEL? What's the difference?
This has been beaten to death already. It's not in RHEL. It's in the RHS Channel for RHSA. Some client-side bits will eventually be released in RHEL7.
Just to be clear, it's been extensively discussed on an epel list @redhat. Sorry for for the omission.
As for the RHS Channel and RHSA, suffice it to say, it's not RHEL. That's the key point.
There seems to be some small consensus that not shipping glusterfs-3.3.x on f16 and f17 is the correct strategy, and I'm happy with that. And if everyone else is happy with that then no rename is necessary.
Yes, for the Fedora side of things I think gluster 3.2 is the best strategy with a fedorapeople repo of 3.3 if it's considered worthwhile for those that wish to play. For gluster 3.3 I suggest a feature page for F-18 / rawhide. Is it feasible for the missing hekafs features to be merged into the 3.3 release train by October when F-18 is due to be released?
For the EPEL side possibly it might be worth going the glusterfs32 naming route and keep it simple and move it forward.
Peter
On 05/30/2012 02:23 PM, Peter Robinson wrote:
Yes, for the Fedora side of things I think gluster 3.2 is the best strategy with a fedorapeople repo of 3.3 if it's considered worthwhile for those that wish to play. For gluster 3.3 I suggest a feature page for F-18 / rawhide. Is it feasible for the missing hekafs features to be merged into the 3.3 release train by October when F-18 is due to be released?
I was under the impression that glusterfs would be automatically carried forward from f17 into f18, as it apparently was from f16 into f17.
F18 builds (of 3.2.6) are already available in koji. Until now I haven't heard that a feature page is needed for 3.2.x (or 3.3.x) to be included in f18. (But how to deprecate HekaFS on f18 once the glusterfs-3.3.0 build is available.)
The features that are in HekaFS (in f16 and f17) will get merged into glusterfs-3.3.1+, as I indicated previously, but I won't promise how many of them will be there when f18 ships. We certainly hope that all of them will be, but we aren't making any promises.
For the EPEL side possibly it might be worth going the glusterfs32 naming route and keep it simple and move it forward.
Peter
On 05/30/2012 03:03 PM, Kaleb S. KEITHLEY wrote:
On 05/30/2012 02:23 PM, Peter Robinson wrote:
Yes, for the Fedora side of things I think gluster 3.2 is the best strategy with a fedorapeople repo of 3.3 if it's considered worthwhile for those that wish to play. For gluster 3.3 I suggest a feature page for F-18 / rawhide. Is it feasible for the missing hekafs features to be merged into the 3.3 release train by October when F-18 is due to be released?
I was under the impression that glusterfs would be automatically carried forward from f17 into f18, as it apparently was from f16 into f17.
It is, barring a newer build in the f18 target.
F18 builds (of 3.2.6) are already available in koji. Until now I haven't heard that a feature page is needed for 3.2.x (or 3.3.x) to be included in f18. (But how to deprecate HekaFS on f18 once the glusterfs-3.3.0 build is available.)
No feature page is required, but in cases of notable changes in functionality, it is usually worthwhile.
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
The features that are in HekaFS (in f16 and f17) will get merged into glusterfs-3.3.1+, as I indicated previously, but I won't promise how many of them will be there when f18 ships. We certainly hope that all of them will be, but we aren't making any promises.
Fair enough. I still think 3.3+ in f18+ makes the most sense.
~tom
== Fedora Project
On Wed, May 30, 2012 at 8:03 PM, Kaleb S. KEITHLEY kkeithle@redhat.com wrote:
On 05/30/2012 02:23 PM, Peter Robinson wrote:
Yes, for the Fedora side of things I think gluster 3.2 is the best strategy with a fedorapeople repo of 3.3 if it's considered worthwhile for those that wish to play. For gluster 3.3 I suggest a feature page for F-18 / rawhide. Is it feasible for the missing hekafs features to be merged into the 3.3 release train by October when F-18 is due to be released?
I was under the impression that glusterfs would be automatically carried forward from f17 into f18, as it apparently was from f16 into f17.
It will be carried forward but a major change of features and enhancements is worth doing a feature page to advertise the feature improvements (see the gnome feature page as an example[1] ), it's something for marketing to use and allows you to also detail things like the removal or merge of HekaFS.
F18 builds (of 3.2.6) are already available in koji. Until now I haven't heard that a feature page is needed for 3.2.x (or 3.3.x) to be included in f18. (But how to deprecate HekaFS on f18 once the glusterfs-3.3.0 build is available.)
See above for feature page details. For deprecate HekaFS you add the the appropriate obsoletes/provides as necessary to the gluster package and follow the process for removing/obsoleteing a package in the wiki.
The features that are in HekaFS (in f16 and f17) will get merged into glusterfs-3.3.1+, as I indicated previously, but I won't promise how many of them will be there when f18 ships. We certainly hope that all of them will be, but we aren't making any promises.
So that's something that can be documented in a feature page in the wiki and updated as things progress through both the gluster devel process and the fedora release process :)
Peter
On Wed, May 30, 2012 at 12:25 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Wed, May 30, 2012 at 8:03 PM, Kaleb S. KEITHLEY kkeithle@redhat.com wrote:
On 05/30/2012 02:23 PM, Peter Robinson wrote:
Yes, for the Fedora side of things I think gluster 3.2 is the best strategy with a fedorapeople repo of 3.3 if it's considered worthwhile for those that wish to play. For gluster 3.3 I suggest a feature page for F-18 / rawhide. Is it feasible for the missing hekafs features to be merged into the 3.3 release train by October when F-18 is due to be released?
I was under the impression that glusterfs would be automatically carried forward from f17 into f18, as it apparently was from f16 into f17.
It will be carried forward but a major change of features and enhancements is worth doing a feature page to advertise the feature improvements (see the gnome feature page as an example[1] ), it's something for marketing to use and allows you to also detail things like the removal or merge of HekaFS.
F18 builds (of 3.2.6) are already available in koji. Until now I haven't heard that a feature page is needed for 3.2.x (or 3.3.x) to be included in f18. (But how to deprecate HekaFS on f18 once the glusterfs-3.3.0 build is available.)
See above for feature page details. For deprecate HekaFS you add the the appropriate obsoletes/provides as necessary to the gluster package and follow the process for removing/obsoleteing a package in the wiki.
The features that are in HekaFS (in f16 and f17) will get merged into glusterfs-3.3.1+, as I indicated previously, but I won't promise how many of them will be there when f18 ships. We certainly hope that all of them will be, but we aren't making any promises.
So that's something that can be documented in a feature page in the wiki and updated as things progress through both the gluster devel process and the fedora release process :)
Okay, as a slightly more detailed version:
You should follow the full feature process, to be put in the FeatureList for F18. If you want to see what that process looks like, you probably want to look at this diagram:
https://fedoraproject.org/wiki/Features/Policy/Process
And make your feature page according to the template noted on that wiki page, and submit it to the feature wrangler (via a wiki category change) so that they can have it approved by fesco, at which point it can be added to the actual feature list :)
-robyn
Peter
[1] https://fedoraproject.org/wiki/Features/Gnome3.4
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 06/06/2012 07:56 AM, Robyn Bergeron wrote:
On Wed, May 30, 2012 at 12:25 PM, Peter Robinsonpbrobinson@gmail.com wrote:
On Wed, May 30, 2012 at 8:03 PM, Kaleb S. KEITHLEYkkeithle@redhat.com wrote:
On 05/30/2012 02:23 PM, Peter Robinson wrote:
Yes, for the Fedora side of things I think gluster 3.2 is the best strategy with a fedorapeople repo of 3.3 if it's considered worthwhile for those that wish to play. For gluster 3.3 I suggest a feature page for F-18 / rawhide. Is it feasible for the missing hekafs features to be merged into the 3.3 release train by October when F-18 is due to be released?
I was under the impression that glusterfs would be automatically carried forward from f17 into f18, as it apparently was from f16 into f17.
It will be carried forward but a major change of features and enhancements is worth doing a feature page to advertise the feature improvements (see the gnome feature page as an example[1] ), it's something for marketing to use and allows you to also detail things like the removal or merge of HekaFS.
F18 builds (of 3.2.6) are already available in koji. Until now I haven't heard that a feature page is needed for 3.2.x (or 3.3.x) to be included in f18. (But how to deprecate HekaFS on f18 once the glusterfs-3.3.0 build is available.)
See above for feature page details. For deprecate HekaFS you add the the appropriate obsoletes/provides as necessary to the gluster package and follow the process for removing/obsoleteing a package in the wiki.
The features that are in HekaFS (in f16 and f17) will get merged into glusterfs-3.3.1+, as I indicated previously, but I won't promise how many of them will be there when f18 ships. We certainly hope that all of them will be, but we aren't making any promises.
So that's something that can be documented in a feature page in the wiki and updated as things progress through both the gluster devel process and the fedora release process :)
Okay, as a slightly more detailed version:
You should follow the full feature process, to be put in the FeatureList for F18. If you want to see what that process looks like, you probably want to look at this diagram:
https://fedoraproject.org/wiki/Features/Policy/Process
And make your feature page according to the template noted on that wiki page, and submit it to the feature wrangler (via a wiki category change) so that they can have it approved by fesco, at which point it can be added to the actual feature list :)
-robyn
The short version of this is that HekaFS used to be an independent set of features on top of glusterfs that are now moving into the core of glusterfs. That is a glusterfs community decision, not a fedora project per se.
When we update the gluster code in Fedora, we will get this change and the hekafs packages will be obsolete.
Do we really need to create a feature page for that and follow the approval process?
Seems too heavy weight to me for effectively rebasing a package...
thanks!
Ric
On 06/07/2012 05:29 AM, Ric Wheeler wrote:
Do we really need to create a feature page for that and follow the approval process?
Seems too heavy weight to me for effectively rebasing a package...
It is certainly not required. Feature process is a marketing and coordination tool. Not a bureaucracy to rubber stamp merely a rebase. Use it only where it makes sense. In this case, you only need it if you want to advertise this change heavily.
Rahul
On 06/07/2012 01:04 PM, Rahul Sundaram wrote:
On 06/07/2012 05:29 AM, Ric Wheeler wrote:
Do we really need to create a feature page for that and follow the approval process?
Seems too heavy weight to me for effectively rebasing a package...
It is certainly not required. Feature process is a marketing and coordination tool. Not a bureaucracy to rubber stamp merely a rebase. Use it only where it makes sense. In this case, you only need it if you want to advertise this change heavily.
Rahul
Thanks - I think that it probably does make sense to highlight the updates in a Fedora Feature page going into gluster more generally, this could be one item of several that we want to highlight when we get to the newer community version....
Ric
-
Kaleb S. KEITHLEY -
Ken Dreyer -
Peter Robinson -
Rahul Sundaram -
Ric Wheeler -
Richard W.M. Jones -
Robyn Bergeron -
Tom Callaway