OK from the various problems with various packages and the needs of packaging groups for a faster place for development and users for a more stable and knowing release cycle.. I would like to open the floor to what we can do to make EPEL more useful to both groups as best as possible with the goal that the proposals are finalized by FUDcon Lawrence and work on them completed within 6 months.
1) Formalize what EPEL does and how it does it. - Who gets to decide about updates - How do we update major items (regularly after a RHEL release? after a Fedora release?) - How do we say "we can't support this architecture/release" anymore? 2) Make sure it is documented what the Fedora Build System can do for us and what it can't. - Repotags (yes/no) - Multiple channels for devel, testing, stable, old (yes/no)? - Building for PPC/etc architectures when we don't have systems anymore?
On Wed, Nov 21, 2012 at 11:21 AM, Stephen John Smoogen smooge@gmail.com wrote:
OK from the various problems with various packages and the needs of packaging groups for a faster place for development and users for a more stable and knowing release cycle.. I would like to open the floor to what we can do to make EPEL more useful to both groups as best as possible with the goal that the proposals are finalized by FUDcon Lawrence and work on them completed within 6 months.
- Formalize what EPEL does and how it does it.
- Who gets to decide about updates
- How do we update major items (regularly after a RHEL release? after
a Fedora release?)
- How do we say "we can't support this architecture/release" anymore?
- Make sure it is documented what the Fedora Build System can do for
us and what it can't.
- Repotags (yes/no)
- Multiple channels for devel, testing, stable, old (yes/no)?
- Building for PPC/etc architectures when we don't have systems anymore?
I'd love to be a part of this discussion, but I won't be at the FUDcon. I'd be happy to block time on calendars and such to attend/discuss remotely.
Mike
-- Stephen J Smoogen. "Don't derail a useful feature for the 99% because you're not in it." Linus Torvalds "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On 21 November 2012 16:44, Michael Stahnke stahnma@puppetlabs.com wrote:
On Wed, Nov 21, 2012 at 11:21 AM, Stephen John Smoogen smooge@gmail.com wrote:
OK from the various problems with various packages and the needs of packaging groups for a faster place for development and users for a more stable and knowing release cycle.. I would like to open the floor to what we can do to make EPEL more useful to both groups as best as possible with the goal that the proposals are finalized by FUDcon Lawrence and work on them completed within 6 months.
- Formalize what EPEL does and how it does it.
- Who gets to decide about updates
- How do we update major items (regularly after a RHEL release? after
a Fedora release?)
- How do we say "we can't support this architecture/release" anymore?
- Make sure it is documented what the Fedora Build System can do for
us and what it can't.
- Repotags (yes/no)
- Multiple channels for devel, testing, stable, old (yes/no)?
- Building for PPC/etc architectures when we don't have systems anymore?
I'd love to be a part of this discussion, but I won't be at the FUDcon. I'd be happy to block time on calendars and such to attend/discuss remotely.
Well the discussion needs to be now til FUDcon. At FUDcon the die will be cast and rubicon will be crossed. Then by next July, I will be stabbed by my fellow senators going "Et Tu Inode0?"
On Wed, Nov 21, 2012 at 6:00 PM, Stephen John Smoogen smooge@gmail.com wrote:
Well the discussion needs to be now til FUDcon. At FUDcon the die will be cast and rubicon will be crossed. Then by next July, I will be stabbed by my fellow senators going "Et Tu Inode0?"
That does it. I am packing my toga.
John
On 11/21/2012 11:21 AM, Stephen John Smoogen wrote:
OK from the various problems with various packages and the needs of packaging groups for a faster place for development and users for a more stable and knowing release cycle.. I would like to open the floor to what we can do to make EPEL more useful to both groups as best as possible with the goal that the proposals are finalized by FUDcon Lawrence and work on them completed within 6 months.
- Formalize what EPEL does and how it does it.
- Who gets to decide about updates
- How do we update major items (regularly after a RHEL release? after
a Fedora release?)
- How do we say "we can't support this architecture/release" anymore?
- Make sure it is documented what the Fedora Build System can do for
us and what it can't.
- Repotags (yes/no)
- Multiple channels for devel, testing, stable, old (yes/no)?
- Building for PPC/etc architectures when we don't have systems anymore?
As much as I've balked at not being able to get the more stable GlusterFS release(s) into EPEL, I do agree with the Enterprise standpoint.
GlusterFS, prior to 3.1.6 had no business being in an enterprise repo. It wasn't ready. Unfortunately, since it was already in, it wasn't possible to push any of the versions that/were/ enterprise ready. If it had been kept out until it was ready, I would sure have a much easier time supporting it. Better than half the time someone comes into #gluster, they're running the EPEL version and I have to tell them to upgrade because whichever bug they're experiencing has already been fixed.
This should also be taken into account in this process: - Should a package reside outside of EPEL until it's "enterprise ready"? IMHO, that's what Fedora's for. - How is it decided that a software is "enterprise ready", and who gets to decide?
On 11/21/2012 08:21 PM, Stephen John Smoogen wrote:
OK from the various problems with various packages and the needs of packaging groups for a faster place for development and users for a more stable and knowing release cycle.. I would like to open the floor to what we can do to make EPEL more useful to both groups as best as possible with the goal that the proposals are finalized by FUDcon Lawrence and work on them completed within 6 months.
- Formalize what EPEL does and how it does it.
- Who gets to decide about updates
- How do we update major items (regularly after a RHEL release? after
a Fedora release?)
- How do we say "we can't support this architecture/release" anymore?
- Make sure it is documented what the Fedora Build System can do for
us and what it can't.
- Repotags (yes/no)
- Multiple channels for devel, testing, stable, old (yes/no)?
- Building for PPC/etc architectures when we don't have systems anymore?
For some packages, keeping them up to date and 100% compatible to a version released, when that package was added to EPEL is simply impossible for volunteers. As (bad) example, php in RHEL 6 is php-5.3.3, latest stable release is php-5.4.8; I'm taking my hat off for everybody back-porting fixes for every error fixed in between those releases.
<rant> When reading php's changelogs, you ask yourself, how you were ever able to use that software on a server.</rant>
But clearly there's software requiring more frequent upgrades than other software. An example for the former is php, for the latter the Apache web server, which has been stable (and compatible) for at least 7 (?) years.
To come to my proposal: We should have something like channels, for simplicity analogous to EPEL releases (i.e. RHEL releases). When a newer channel is opened (i.e. a newer RHEL minor version is released), EPEL package maintainers should be allowed to do upgrades.
A configuration would look like today, but would also include repositories for those (additional) sub-channels. So users could stay at the base channel as long as the release lives or could upgrade by adding a sub channel.
The question here is: can we realize this setting somehow in our repos (and also in our builders)? Honestly, I don't know.
On Thu, Nov 22, 2012 at 10:15:30AM +0100, Matthias Runge wrote:
For some packages, keeping them up to date and 100% compatible to a version released, when that package was added to EPEL is simply impossible for volunteers. As (bad) example, php in RHEL 6 is php-5.3.3, latest stable release is php-5.4.8; I'm taking my hat off for everybody back-porting fixes for every error fixed in between those releases.
[...]
To come to my proposal: We should have something like channels, for simplicity analogous to EPEL releases (i.e. RHEL releases). When a newer channel is opened (i.e. a newer RHEL minor version is released), EPEL package maintainers should be allowed to do upgrades.
The schedules RHEL operates on are not necessarily aligned with the schedules of the individual components in EPEL. Having more channels / streams of EPEL could lead to unnecessary increase of work for maintainers who'd suddenly face much more complex rel-eng setup.
I believe there are fundamentaly conflicting interests of different groups of people WRT the stability of the package versions vs. access to new technology. Often even a single person may have different needs and expectations from one package (I really depend on *this on* to be stable) vs. another one (upstream has these new cool features that I'd like).
For your php example above, wouldn't the solution be to name one package php53, another php54, and let people happy with 5.3 stay with php53 while people who want to move on would have to knowingly replace the packages? The packages would install to the same paths so they would conflict and you'd need to pick one.
In Spacewalk project, we've seen our users were recently hit by a rebase of one EPEL component that broke long-time users of the original version. We ended up having to package the original version under different name in Spacewalk (to avoid upgrade to EPEL's version by accident). Maybe if this approach became the preferred one in EPEL, to provide both versions, we could put the package to EPEL directly.
On 11/22/2012 10:56 AM, Jan Pazdziora wrote:
The schedules RHEL operates on are not necessarily aligned with the schedules of the individual components in EPEL. Having more channels / streams of EPEL could lead to unnecessary increase of work for maintainers who'd suddenly face much more complex rel-eng setup.
I totally agree. A more complex setup should be avoided. My intention was to be able to upgrade packages without breaking installations of people interested on just stable infrastructure.
I believe there are fundamentaly conflicting interests of different groups of people WRT the stability of the package versions vs. access to new technology. Often even a single person may have different needs and expectations from one package (I really depend on *this on* to be stable) vs. another one (upstream has these new cool features that I'd like).
For your php example above, wouldn't the solution be to name one package php53, another php54, and let people happy with 5.3 stay with php53 while people who want to move on would have to knowingly replace the packages? The packages would install to the same paths so they would conflict and you'd need to pick one.
You're thinking about php53 also providing php = %{version}-%{release}? Otherwise you'd produce an interesting pile of dependencies. Those packages also need to obsolete the older packages and must be marked as conflicting, to prevent unintentional upgrades. Did I miss something?
What about a package upgrade, which requires upgrades of several packages? Following your proposal this IMHO makes several manual steps necessary.
On Thu, Nov 22, 2012 at 11:30:27AM +0100, Matthias Runge wrote:
You're thinking about php53 also providing php = %{version}-%{release}?
Yes.
Otherwise you'd produce an interesting pile of dependencies. Those packages also need to obsolete the older packages and must be marked as
They can.
conflicting, to prevent unintentional upgrades. Did I miss something?
They don't have to really -- the conflict will be on the files level.
What about a package upgrade, which requires upgrades of several packages? Following your proposal this IMHO makes several manual steps necessary.
Yes. And that's the point -- if you have php53 installed, it should not be easy for you to shoot yourself to the foot to by upgrading to php54 or php == 5.5 or something. You probably moved to php53 to stay on that version.
On Thu, Nov 22, 2012 at 11:40:28AM +0100, Jan Pazdziora wrote:
On Thu, Nov 22, 2012 at 11:30:27AM +0100, Matthias Runge wrote:
You're thinking about php53 also providing php = %{version}-%{release}?
Yes.
Otherwise you'd produce an interesting pile of dependencies. Those packages also need to obsolete the older packages and must be marked as
They can.
Actually -- maybe not. We would need to check if that would lead yum to upgrade php53 to php54 because php53 was providing php = 5.3 and php54 obsoleted php < 5.4.
On 11/22/2012 11:42 AM, Jan Pazdziora wrote:
On Thu, Nov 22, 2012 at 11:40:28AM +0100, Jan Pazdziora wrote:
On Thu, Nov 22, 2012 at 11:30:27AM +0100, Matthias Runge wrote:
You're thinking about php53 also providing php = %{version}-%{release}?
Yes.
Otherwise you'd produce an interesting pile of dependencies. Those packages also need to obsolete the older packages and must be marked as
They can.
Actually -- maybe not. We would need to check if that would lead yum to upgrade php53 to php54 because php53 was providing php = 5.3 and php54 obsoleted php < 5.4.
Exactly.
I took that road with Django14 as an updated Django package. If I remember right, I was forced to use conflict to prevent version upgrades, but I might be wrong.
On 11/22/2012 11:40 AM, Jan Pazdziora wrote:
Yes. And that's the point -- if you have php53 installed, it should not be easy for you to shoot yourself to the foot to by upgrading to php54 or php == 5.5 or something. You probably moved to php53 to stay on that version.
Yes.
Given you have php53 installed and an application which requires php53. Then a newer version of your application is released to EPEL, now requiring php55, as php >= 5.5 (and also implicitly php55-mysql55 and also php55-ldap) which where previously installed as their php53 counterparts. The point is, this makes it a real pain to upgrade each package individually, because dependencies can't be solved automatically.
Using requirements php55 as opposite to requires php >= 5.5 for the above application is nonsense, but would you enable to solve dependencies. You're introducing several packages providing the same capability. Is yum's dependency resolver capable to solve that deterministic? What about other updaters?
On Thu, 22 Nov 2012 10:56:33 +0100 Jan Pazdziora jpazdziora@redhat.com wrote:
On Thu, Nov 22, 2012 at 10:15:30AM +0100, Matthias Runge wrote:
For some packages, keeping them up to date and 100% compatible to a version released, when that package was added to EPEL is simply impossible for volunteers. As (bad) example, php in RHEL 6 is php-5.3.3, latest stable release is php-5.4.8; I'm taking my hat off for everybody back-porting fixes for every error fixed in between those releases.
[...]
To come to my proposal: We should have something like channels, for simplicity analogous to EPEL releases (i.e. RHEL releases). When a newer channel is opened (i.e. a newer RHEL minor version is released), EPEL package maintainers should be allowed to do upgrades.
The schedules RHEL operates on are not necessarily aligned with the schedules of the individual components in EPEL. Having more channels / streams of EPEL could lead to unnecessary increase of work for maintainers who'd suddenly face much more complex rel-eng setup.
And does every package have to be present in all the channels? I can imagine a package having a different maintainer in each channel or not to be present in some at all: if maintaining more versions at once or backporting patches is beyond the maintainers possibilities, he may decide to only re-package the new upstream stuff in "unstable" or just backport critical patches to the "old" channel.
Yes, I understand this may shift the complications to the users who will have to invent more complicated yum configurations to get the right packages from the right channels.
Regards,
On 11/23/2012 09:47 AM, Tomáš Smetana wrote:
And does every package have to be present in all the channels? I can imagine a package having a different maintainer in each channel or not to be present in some at all: if maintaining more versions at once or backporting patches is beyond the maintainers possibilities, he may decide to only re-package the new upstream stuff in "unstable" or just backport critical patches to the "old" channel.
Yes, I understand this may shift the complications to the users who will have to invent more complicated yum configurations to get the right packages from the right channels.
Regards,
In my opinion, it's not necessary to have each package in each repository. Yum will do it's magic and select that package with the highest version number. E.g if you choose just the base EPEL-6 branch, then you should get the latest version of your desired package from there. If you also enabled e.g. EPEL-6.1 and the package from there is newer, then yum will fetch it from there. If that package doesn't exist there, you'll get, what's in EPEL-6.
So using newer versions which may include upgrades, you'll need to enable another repository. But to be clear, I just intend ONE version upgrade for a package for each new repo, so when you chose to enable that newer repo, you'll stick on that provided version.
Matthias
I've been sitting on this too long... so just wanted to get it sent. My apologies about the flow.
On Fri, Nov 23, 2012 at 3:27 AM, Matthias Runge mrunge@matthias-runge.dewrote:
On 11/23/2012 09:47 AM, Tomáš Smetana wrote:
And does every package have to be present in all the channels? I can
imagine
a package having a different maintainer in each channel or not to be
present
in some at all: if maintaining more versions at once or backporting
patches
is beyond the maintainers possibilities, he may decide to only
re-package the
new upstream stuff in "unstable" or just backport critical patches to the "old" channel.
Yes, I understand this may shift the complications to the users who will
have
to invent more complicated yum configurations to get the right packages
from
the right channels.
Regards,
In my opinion, it's not necessary to have each package in each repository. Yum will do it's magic and select that package with the highest version number. E.g if you choose just the base EPEL-6 branch, then you should get the latest version of your desired package from there. If you also enabled e.g. EPEL-6.1 and the package from there is newer, then yum will fetch it from there. If that package doesn't exist there, you'll get, what's in EPEL-6.
So using newer versions which may include upgrades, you'll need to enable another repository. But to be clear, I just intend ONE version upgrade for a package for each new repo, so when you chose to enable that newer repo, you'll stick on that provided version.
TL;DR - stability is nice - longer RHEL lifecycle = less useful EPEL if there are no updates - shouldn't be expected to solve local admin software management issues -
So... I agree with a lot of the overall concerns about stability, however realistic expectations should be set on volunteers. I also think we'd want to avoid deviating to far from RHEL's update cycle beyond is absolutely necessary (i'm referring to the concept of dot release repositories).
As an administrator I know it has annoyed me for years that I can't specifically get many apps from EPEL just because of the major version update rule. In my experience I've ended up repackaging the Fedora RPM because EPEL was just too far behind.
So, first, be patient with me as I look at RHEL for a second.
* Red Hat's release cycle for RHEL is ~8m per dot release (roughly averaged) * RHEL is now on a 13 year support cycle ( https://access.redhat.com/support/policy/updates/errata/) * Updated always go into the same repository (Unless you subscribe to Extended Update Support (EUS), but I believe that is a separate repository anyway)
Based on the above, most people have come up with a way to handle deployment of updates in their environment:
1: paying extra to red hat for EUS 2: running a local repository that they manage the releases through (satellite or manual) 3: auto or manually updating the boxes on a schedule 4: updating haphazardly 5: other?
So, unless someone wants to turn EPEL into a paid service, #1 is out (hey... thats an interesting concept...)
To me (and most people I know) running your own local repository as a 'stability' control is way more efficient for the administrator.
If you are doing 3 and 4 then I don't know that requesting the EPEL volunteers to provide that level of stability is very reasonable.
I can however appreciate that there are two primary sets of users from what I've read on these conversations:
1: Those that don't want updates that change api compatibility 2: Those who need the newer version for X reason
I'm personally inclined to lean toward the concept I was pushing in the thread discussing multiple versions [1]. I'd imagine that a 'api stable' repo and a 'rolling' repo would be less support effort than attempting to manage >8 repositories per major release and the security updates that need to be applied on older version.
That being said I could about see doing a point in time 'snapshot' using hardlinks of the single repository whenever a dot release comes out. But then what about security updates?
I realize that whichever route we go, work is required, but I also assume that as a given at this point of the conversation.
-greg
On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift gregswift@gmail.com wrote:
I'm personally inclined to lean toward the concept I was pushing in the thread discussing multiple versions [1]. I'd imagine that a 'api stable' repo and a 'rolling' repo would be less support effort than attempting to manage >8 repositories per major release and the security updates that need to be applied on older version.
My main concern with multiple EPEL repos is that users will be in a worse condition security-wise. Many users will download an application from the "api stable" repo, but they will not realize that no one is doing backports any more, because all the interested EPEL maintainers left that behind to focus on the "rolling" repo.
The analogy that comes to my mind is Fedora: What if we kept old Fedora releases going back all the way to Fedora 6 open to maintainers to patch on a voluntary basis, and we never really announced EOL for any Fedora release? Fedora users would have to know enough to keep jumping along with whatever's maintained.
It seems to me that we have to choose between occasional instability and insecurity. I'd rather EPEL's reputation err on the side of instability rather than insecurity.
So, unless someone wants to turn EPEL into a paid service, #1 is out (hey... thats an interesting concept...)
Maybe money does have to enter the picture at some point. Corporations should commit to pay salaries for more developers to do EPEL backports if it's important to their businesses.
- Ken
On Tue, Dec 4, 2012 at 5:46 PM, Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift gregswift@gmail.com wrote:
I'm personally inclined to lean toward the concept I was pushing in the thread discussing multiple versions [1]. I'd imagine that a 'api stable' repo and a 'rolling' repo would be less support effort than attempting to manage >8 repositories per major release and the security updates that
need
to be applied on older version.
My main concern with multiple EPEL repos is that users will be in a worse condition security-wise. Many users will download an application from the "api stable" repo, but they will not realize that no one is doing backports any more, because all the interested EPEL maintainers left that behind to focus on the "rolling" repo.
The analogy that comes to my mind is Fedora: What if we kept old Fedora releases going back all the way to Fedora 6 open to maintainers to patch on a voluntary basis, and we never really announced EOL for any Fedora release? Fedora users would have to know enough to keep jumping along with whatever's maintained.
It seems to me that we have to choose between occasional instability and insecurity. I'd rather EPEL's reputation err on the side of instability rather than insecurity.
I can back that line of thought. Plus providing 1 path means less change! :)
So, unless someone wants to turn EPEL into a paid service, #1 is out (hey... thats an interesting concept...)
Maybe money does have to enter the picture at some point. Corporations should commit to pay salaries for more developers to do EPEL backports if it's important to their businesses.
So... anyone got any motivation in pushing a product internally @ Red Hat that does this? :)
Also.... I hadn't mentioned it before on here, because in general mentioning tends to mean you have to do it and I don't really have the cycles available. But as of this morning I figured I'd float the concept anyways.
What would it take to basically have a yum plugin would check a 'notification' feed (something simple like rss or atom) about a specific repository. Notifications found on that feed would throw messages in the yum output and /var/log/messages. This feed could provide notices like 'Hey, this version is deprecated and insecure, you need to update'. An extension of this might be that it marks the package as an 'exclude' if it can't just be updated without interference. This would allow a notification method, and a way for users to not get an update if its going to break them, but also allowing the main page to just continuously be updated.
Then this package could possibly be a required package from the epel-release package.
-greg
On 12/05/2012 08:47 AM, Greg Swift wrote:
On Tue, Dec 4, 2012 at 5:46 PM, Ken Dreyer <ktdreyer@ktdreyer.com mailto:ktdreyer@ktdreyer.com> wrote:
On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift <gregswift@gmail.com <mailto:gregswift@gmail.com>> wrote: > I'm personally inclined to lean toward the concept I was pushing in the > thread discussing multiple versions [1]. I'd imagine that a 'api stable' > repo and a 'rolling' repo would be less support effort than attempting to > manage >8 repositories per major release and the security updates that need > to be applied on older version. My main concern with multiple EPEL repos is that users will be in a worse condition security-wise. Many users will download an application from the "api stable" repo, but they will not realize that no one is doing backports any more, because all the interested EPEL maintainers left that behind to focus on the "rolling" repo. The analogy that comes to my mind is Fedora: What if we kept old Fedora releases going back all the way to Fedora 6 open to maintainers to patch on a voluntary basis, and we never really announced EOL for any Fedora release? Fedora users would have to know enough to keep jumping along with whatever's maintained. It seems to me that we have to choose between occasional instability and insecurity. I'd rather EPEL's reputation err on the side of instability rather than insecurity.I can back that line of thought. Plus providing 1 path means less change! :)
> So, unless someone wants to turn EPEL into a paid service, #1 is out > (hey... thats an interesting concept...) Maybe money does have to enter the picture at some point. Corporations should commit to pay salaries for more developers to do EPEL backports if it's important to their businesses.So... anyone got any motivation in pushing a product internally @ Red Hat that does this? :)
Also.... I hadn't mentioned it before on here, because in general mentioning tends to mean you have to do it and I don't really have the cycles available. But as of this morning I figured I'd float the concept anyways.
What would it take to basically have a yum plugin would check a 'notification' feed (something simple like rss or atom) about a specific repository. Notifications found on that feed would throw messages in the yum output and /var/log/messages. This feed could provide notices like 'Hey, this version is deprecated and insecure, you need to update'. An extension of this might be that it marks the package as an 'exclude' if it can't just be updated without interference. This would allow a notification method, and a way for users to not get an update if its going to break them, but also allowing the main page to just continuously be updated.
Then this package could possibly be a required package from the epel-release package.
-greg
Not volunteering at the moment because I don't have the cycles, but I really like that idea. Something similar, except opposite, of the security plugin. If a package has the "breakable update" option set, then don't update it unless they do the "--reallyupdate" option. But also give them a nag that says the package has an update.
Troy
On Wed, Dec 05, 2012 at 08:58:44AM -0600, Troy Dawson wrote:
Not volunteering at the moment because I don't have the cycles, but I really like that idea. Something similar, except opposite, of the security plugin. If a package has the "breakable update" option set, then don't update it unless they do the "--reallyupdate" option. But also give them a nag that says the package has an update.
+1 to this
On Wed, 5 Dec 2012 10:33:04 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Dec 05, 2012 at 08:58:44AM -0600, Troy Dawson wrote:
Not volunteering at the moment because I don't have the cycles, but I really like that idea. Something similar, except opposite, of the security plugin. If a package has the "breakable update" option set, then don't update it unless they do the "--reallyupdate" option. But also give them a nag that says the package has an update.
+1 to this
-a lot. ;)
Anything that requires someone to read output from updates is doomed.
If I update 100 machines, I am not going to look at all the spew from yum, and if I don't specifically look at my logs often am I going to notice this.
If I install a new machine with updates enabled, would I notice this before the machine was deployed?
I don't think this is a good solution... still trying to think of one. ;)
kevin
On Wed, Dec 5, 2012 at 5:53 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 5 Dec 2012 10:33:04 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Dec 05, 2012 at 08:58:44AM -0600, Troy Dawson wrote:
Not volunteering at the moment because I don't have the cycles, but I really like that idea. Something similar, except opposite, of the security plugin. If a package has the "breakable update" option set, then don't update it unless they do the "--reallyupdate" option. But also give them a nag that says the package has an update.
+1 to this
-a lot. ;)
Anything that requires someone to read output from updates is doomed.
I agree with this sentiment. Which is why you don't _have_ to read output. The automatic exclusion is the plugins behavior, with the goal of leaving your system in a running state. Any output is there to provide an explanation for the lack of an update when looked for.
Ideally, we are talking about defining an expected system behavior. It will take communication on top of the plugin creation and feed updating.
A specific scenario that raises accountability concerns would be if the package I have installed is a security risk and the only fix is the 'breakable update'. To address that would be a state such as 'required breakable update - security risk'. If you attempt update all, yum would fail out with an error explaining why. This is the only time I'd suggest an actual error because of the accountability aspect. The error prevents it from being completely ignored, unless the result of the process is blatantly ignored, and I can't help there.
If there is a requirement to stay on the 'insecure' version, place the package into the standard exclude list and then this would not come into play.
The plugin would have to support the concept of versioning. Allowing definitions along the lines of:
package version 2+ is a breakable update for versions <2 or 1.*
Not only does this keep the feed content smaller, as it isn't required for every released version, but if there needs to be a security update for the 1.* release, that is doable without interfering with the 2.* releases while using the same repository.
If designed and implemented well this might be an interesting path towards allowing newer versions of lots of software, even in base RHEL. Obviously, it wouldn't work for everything... but it has potential.
If I update 100 machines, I am not going to look at all the spew from yum, and if I don't specifically look at my logs often am I going to notice this.
So, I feel that falls under the realm of an admins responsibility, and most facilitation for the handling of it should readily come from what is described above. Its not like I'm suggesting we push a potentially broken package, I'm talking about letting their system keep running as it is, unless they specifically update it.
If I install a new machine with updates enabled, would I notice this
before the machine was deployed?
This concept is specific to updates, not fresh installs. During a new install one would get the latest version of the software available , just like today. If a specific version is defined, and there is a 'breakable update' available before you deploy, then no, it would not be installed on a 'yum update'.
-greg
On 6 December 2012 10:13, Greg Swift gregswift@gmail.com wrote:
On Wed, Dec 5, 2012 at 5:53 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 5 Dec 2012 10:33:04 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Dec 05, 2012 at 08:58:44AM -0600, Troy Dawson wrote:
Not volunteering at the moment because I don't have the cycles, but I really like that idea. Something similar, except opposite, of the security plugin. If a package has the "breakable update" option set, then don't update it unless they do the "--reallyupdate" option. But also give them a nag that says the package has an update.
+1 to this
-a lot. ;)
Anything that requires someone to read output from updates is doomed.
I agree with this sentiment. Which is why you don't _have_ to read output. The automatic exclusion is the plugins behavior, with the goal of leaving your system in a running state. Any output is there to provide an explanation for the lack of an update when looked for.
Ideally, we are talking about defining an expected system behavior. It will take communication on top of the plugin creation and feed updating.
Ok looking at the security plugin code it seems it bases its decisions on what is already stored in the repodata. That being the case any sort of plugin is going to need to have extra stuff stored in repodata which means changes to createrepo, rpm, yum-utils, and yum. I don't think this is going to happen so we might as well look for some other solution.
On Thu, Dec 06, 2012 at 10:45:54AM -0700, Stephen John Smoogen wrote:
Ok looking at the security plugin code it seems it bases its decisions on what is already stored in the repodata. That being the case any sort of plugin is going to need to have extra stuff stored in repodata which means changes to createrepo, rpm, yum-utils, and yum. I don't think this is going to happen so we might as well look for some other solution.
Why not? The security metadata wasn't always there and _that_ feature got added.
On 6 December 2012 10:58, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Dec 06, 2012 at 10:45:54AM -0700, Stephen John Smoogen wrote:
Ok looking at the security plugin code it seems it bases its decisions on what is already stored in the repodata. That being the case any sort of plugin is going to need to have extra stuff stored in repodata which means changes to createrepo, rpm, yum-utils, and yum. I don't think this is going to happen so we might as well look for some other solution.
Why not? The security metadata wasn't always there and _that_ feature got added.
It got added before RHEL-6 was out the door. EPEL does not control yum, createrepo, rpm or yum-utils for Red Hat Enterprise Linux. Getting it into there means working with Fedora yum/rpm developers on how it will be stored.. getting it working in Fedora, then figuring out how to back port that to the RHEL-5 and RHEL-6 yum's. Then working with Red Hat on allowing for a large ABI break where old yum users are guarenteed to still be able to make yum commands without yum crashing and that new yum users won't crash when reading old yum repos.
-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mattdm@fedoraproject.org
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Thu, Dec 6, 2012 at 12:11 PM, Stephen John Smoogen smooge@gmail.comwrote:
On 6 December 2012 10:58, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Dec 06, 2012 at 10:45:54AM -0700, Stephen John Smoogen wrote:
Ok looking at the security plugin code it seems it bases its decisions on what is already stored in the repodata. That being the case any sort of plugin is going to need to have extra stuff stored in repodata which means changes to createrepo, rpm, yum-utils, and yum. I don't think this is going to happen so we might as well look for some other solution.
Why not? The security metadata wasn't always there and _that_ feature got added.
It got added before RHEL-6 was out the door. EPEL does not control yum, createrepo, rpm or yum-utils for Red Hat Enterprise Linux. Getting it into there means working with Fedora yum/rpm developers on how it will be stored.. getting it working in Fedora, then figuring out how to back port that to the RHEL-5 and RHEL-6 yum's. Then working with Red Hat on allowing for a large ABI break where old yum users are guarenteed to still be able to make yum commands without yum crashing and that new yum users won't crash when reading old yum repos.
If updateinfo.xml could store the data, would the addition of an alternate 'update' type break existing systems? From what I can tell updateinfo.xml is populated by parsing errata feeds. If this data could be presented as a specifically formatted errata, which to me makes a bit on sense because its just an update, then the updateinfo.xml generator and the plugin would be the primary change points. As long as the clients don't blow up at an alternate <update type='breakable'> or whatever, then maybe there wouldn't be a large ABI break.
A few more questions:
- Who is going to write/maintain this plugin? :)
- How do you plan on making sure everyone using EPEL is using the plugin? Have a Requires in epel-release? That strikes me as pretty ugly.
- Who is going to update all the compose/build tools/scripts to handle this metadata.
- How is the metadata added? By maintainer? What if they don't update it?
- What are the metadata keywords?
* Breakable = excluding this update because it needs intervention * Insecure = this package is no longer updated and insecure ?
- How do you handle trains of updates?
foo-1.0-1 pushes out to stable <time passes> foo-2.0-1 pushes out, marked 'breakable' because you have to manually update configs. <time passes> foo-3.0-1 comes out, it's compatible with 2.0-1, no changes needed.
Does someone still on 1.0-1 get upgraded to 3.0-1 since it's not incompatible marked?
kevin
On Thu, Dec 6, 2012 at 2:05 PM, Kevin Fenzi kevin@scrye.com wrote:
A few more questions:
- Who is going to write/maintain this plugin? :)
good question. From my understanding that's a question for whatever path is taken. If i'm not mistaken the multiple repository path also required dev work. I'm looking to see if I can generate some free cycles to participate, so its not just me spouting an idea, but thats the most I can offer at this moment aside from these e-mails that are taking me ~24h to write ;) At the very least trying to cover some of the bases in this concept leaves an option and a basic blueprint for an interested party.
- How do you plan on making sure everyone using EPEL is using the plugin? Have a Requires in epel-release? That strikes me as pretty ugly.
yes, it is pretty ugly, but prettier than having people get packages that break their system. The situation I'm more concerned with is the new epel-release going out with the new yum-plugin-whatever. People not updating yet. A month or so later package blah is updated with a breakable update, and they get all 3 at the same time. oops. That's currently the main thing I don't have a suggestion for handling. Suggestions welcome.
- Who is going to update all the compose/build tools/scripts to handle this metadata.
goes back to the first question.
- How is the metadata added? By maintainer? What if they don't update it?
Who generates errata now? I'd lean on the maintainer updating it as they should be the most familiar with it. What happens if a maintainer updates the repository right now with an incompatible update? In theory an update wouldn't get good karma if suddenly it just applied and was broken, or bugs would get created and people would gripe about it. All of which I believe happens already if there is an issue with an update process.
- What are the metadata keywords?
- Breakable = excluding this update because it needs intervention
- Insecure = this package is no longer updated and insecure
?
thats a good start. I'd probably come up with something like 'deprecated' instead of insecure, or maybe have both. This way you could mark unsupported by upsteam packages that may not be "insecure"
obviously we need to flesh out the specific scenarios this process is trying to address and come up with a succinct list of keywords and the associated errata format. Does anyone have any input as to these keywords?
- How do you handle trains of updates?
foo-1.0-1 pushes out to stable
<time passes> foo-2.0-1 pushes out, marked 'breakable' because you have to manually update configs. <time passes> foo-3.0-1 comes out, it's compatible with 2.0-1, no changes needed.
Does someone still on 1.0-1 get upgraded to 3.0-1 since it's not incompatible marked?
The rule that I provided in my original example would apply here:
foo version 2+ is a breakable update for versions <2 or 1.*
The goal would be to have a minimal number of rules per package to reduce overhead, and be able to support up to 13y of updates. To handle newer releases I think that all relevant rules should be applied over the life of the repository.
A prime example would be Zabbix, which in the life cycle of RHEL 5 has gone from 1.4 -> 1.6 -> 1.8 -> 2.0, all of which were breakable upgrades. Here would be the rules in the update:
zabbix* version 1.6+ is a breakable update for versions <1.6 zabbix* version 1.8+ is a breakable update for versions <1.8 zabbix* version 2.0+ is a breakable update for versions <2.0
Theoretically one could even do a partial update, say 1.4 -> 1.8 using 'yum --reallyupdate update-to zabbix-1.8'
Also, would need a good name and cli switch too ;)
On Wed, Dec 5, 2012 at 8:58 AM, Troy Dawson tdawson@redhat.com wrote:
On 12/05/2012 08:47 AM, Greg Swift wrote:
On Tue, Dec 4, 2012 at 5:46 PM, Ken Dreyer <ktdreyer@ktdreyer.com mailto:ktdreyer@ktdreyer.com> wrote:
On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift <gregswift@gmail.com <mailto:gregswift@gmail.com>> wrote: > I'm personally inclined to lean toward the concept I was pushing in the > thread discussing multiple versions [1]. I'd imagine that a 'api stable' > repo and a 'rolling' repo would be less support effort than attempting to > manage >8 repositories per major release and the security updates that need > to be applied on older version. My main concern with multiple EPEL repos is that users will be in a worse condition security-wise. Many users will download anapplication
from the "api stable" repo, but they will not realize that no one is doing backports any more, because all the interested EPEL maintainers left that behind to focus on the "rolling" repo. The analogy that comes to my mind is Fedora: What if we kept old Fedora releases going back all the way to Fedora 6 open tomaintainers
to patch on a voluntary basis, and we never really announced EOL for any Fedora release? Fedora users would have to know enough to keep jumping along with whatever's maintained. It seems to me that we have to choose between occasional instability and insecurity. I'd rather EPEL's reputation err on the side of instability rather than insecurity.I can back that line of thought. Plus providing 1 path means less change! :)
> So, unless someone wants to turn EPEL into a paid service, #1 isout
> (hey... thats an interesting concept...) Maybe money does have to enter the picture at some point.Corporations
should commit to pay salaries for more developers to do EPELbackports
if it's important to their businesses.So... anyone got any motivation in pushing a product internally @ Red Hat that does this? :)
Also.... I hadn't mentioned it before on here, because in general mentioning tends to mean you have to do it and I don't really have the cycles available. But as of this morning I figured I'd float the concept anyways.
What would it take to basically have a yum plugin would check a 'notification' feed (something simple like rss or atom) about a specific repository. Notifications found on that feed would throw messages in the yum output and /var/log/messages. This feed could provide notices like 'Hey, this version is deprecated and insecure, you need to update'. An extension of this might be that it marks the package as an 'exclude' if it can't just be updated without interference. This would allow a notification method, and a way for users to not get an update if its going to break them, but also allowing the main page to just continuously be updated.
Then this package could possibly be a required package from the epel-release package.
-greg
Not volunteering at the moment because I don't have the cycles, but I really like that idea. Something similar, except opposite, of the security plugin. If a package has the "breakable update" option set, then don't update it unless they do the "--reallyupdate" option. But also give them a nag that says the package has an update.
I'm very amused with myself for forgetting about the security plugin (mainly cause I never used it but still...)
Based on some of the previous discussions on this thread, my own self-interests and looking around why not settle for "epel-rawhide" repo that could serve both as a QA stage for packages in EPEL and for the category of users who need "latest and greatest" version of package in RHEL.
I do believe both groups: a) users who want stable b) users who want latest are quite sizable and have enough people involved to power such move.
To address the security concerns: we need something that will require version bump whenever upstream drops maintenance of the currently packaged version in EPEL and there are no takers for backports within a week. That should minimize backporting efforts.
just my $.02CDN
On 12/06/2012 08:58 AM, Dmitry Makovey wrote:
Based on some of the previous discussions on this thread, my own self-interests and looking around why not settle for "epel-rawhide" repo that could serve both as a QA stage for packages in EPEL and for the category of users who need "latest and greatest" version of package in RHEL.
I do believe both groups: a) users who want stable b) users who want latest are quite sizable and have enough people involved to power such move.
To address the security concerns: we need something that will require version bump whenever upstream drops maintenance of the currently packaged version in EPEL and there are no takers for backports within a week. That should minimize backporting efforts.
just my $.02CDN
Taking that a step further, if a packager is unwilling or unable to backport security fixes, not adding them to the stable repo doesn't change anything from the way it's handled presently. With the way it is now where upgrades can break your system, you can't update your packages anyway so you're still not getting security updates. At least a multi-pronged repo would offer that possibility.
Taking, for instance, glusterfs since I'm familiar with the evolution, epel-5 had the very broken 2.0 versions. Those will never get any more bugfixes or security patches. epel-6 had 3.2 which has had several critical patches and will likely get security updates for a while longer. 3.3 is not compatible with the 3.2 rpc but is much more stable and is the recommended version to use by those of us that support glusterfs. For that, Kaleb maintains a fedorapeople repo.
Kaleb's not the only one who supports a newer version of a software in their own fedorapeople repo because it breaks backward compatibility. Todd Zullinger
Having an epel-N-rawhide repo would be one easy way to allow packagers to present the best of their package while leaving a stable repo to minimize the amount of maintenance required by an admin.
I admin 200 systems as just one guy. I don't have time to read every package release. I have to count on stable packaging to not break things. Those things that I want or need bleeding edge packaging are the only ones I track regularly. I don't need to know that libxml2 fixed the out of range heap access in 2.7.6-8.el6_3.4 if it doesn't break something. I don't need to know that Cuba switched to DST in tzdata.
So, I would get behind this, or a "Incompatible-With: " yum/rpm concept that's also being discussed. Really, I'd get behind anything that doesn't require me to read every changelog and prevents (or at least makes it more difficult to have) system outages due to automated updates.
On Thu, Dec 6, 2012 at 3:33 PM, Joe Julian joe@julianfamily.org wrote:
Having an epel-N-rawhide repo would be one easy way to allow packagers to present the best of their package while leaving a stable repo to minimize the amount of maintenance required by an admin.
From my perspective the epel-testing repo fills this gap somewhat. The
advantage to epel-testing is that I can get newer packages, and it is very clear to me what is heading towards stable. We even have feedback mechanisms already in place to support communication back to the maintainers.
However many intermediate repos we put in place, these unstable updates *have* to be allowed to go into epel-stable eventually. Otherwise, we put epel-stable users at risk for unpatched security flaws.
- Ken
On 12/06/2012 03:02 PM, Ken Dreyer wrote:
On Thu, Dec 6, 2012 at 3:33 PM, Joe Julian joe@julianfamily.org wrote:
Having an epel-N-rawhide repo would be one easy way to allow packagers to present the best of their package while leaving a stable repo to minimize the amount of maintenance required by an admin. From my perspective the epel-testing repo fills this gap somewhat. The
advantage to epel-testing is that I can get newer packages, and it is very clear to me what is heading towards stable. We even have feedback mechanisms already in place to support communication back to the maintainers.
However many intermediate repos we put in place, these unstable updates *have* to be allowed to go into epel-stable eventually. Otherwise, we put epel-stable users at risk for unpatched security flaws.
My point is, we already do. If an admin has to lock their packages to specific versions to keep their system working, then they are not going to be getting security updates.
On 12/06/2012 06:23 PM, Joe Julian wrote:
However many intermediate repos we put in place, these unstable updates *have* to be allowed to go into epel-stable eventually. Otherwise, we put epel-stable users at risk for unpatched security flaws.
My point is, we already do. If an admin has to lock their packages to specific versions to keep their system working, then they are not going to be getting security updates.
sounds to me that there needs to be a clean procedure on promoting from testing to stable. My opinion would be to let the users trigger that in cases where developers are busy with other things. So if we have foo-1.x.rpm in epel-stable, and foo-2.y.rpm in epel-testing and I, as a user see that it fixes bug/vulnerability/deprecates/etc. foo-1.x.rpm, I would:
1. submit request for promotion from testing to stable, 2. ... 3. profit?
#2 can go as "need X votes in bugzilla" or "need N confirmations from users" something tangible and simple to follow for all involved.
On 12/07/2012 09:49 PM, Dmitry Makovey wrote:
On 12/06/2012 06:23 PM, Joe Julian wrote:
However many intermediate repos we put in place, these unstable updates *have* to be allowed to go into epel-stable eventually. Otherwise, we put epel-stable users at risk for unpatched security flaws.
My point is, we already do. If an admin has to lock their packages to specific versions to keep their system working, then they are not going to be getting security updates.
sounds to me that there needs to be a clean procedure on promoting from testing to stable. My opinion would be to let the users trigger that in cases where developers are busy with other things. So if we have foo-1.x.rpm in epel-stable, and foo-2.y.rpm in epel-testing and I, as a user see that it fixes bug/vulnerability/deprecates/etc. foo-1.x.rpm, I would:
- submit request for promotion from testing to stable,
- ...
- profit?
#2 can go as "need X votes in bugzilla" or "need N confirmations from users" something tangible and simple to follow for all involved.
Packages need maintainers. If the maintainer of a package cannot deal with these issues any more due to time constraints or lack of interest then the package needs to be orphaned to give others the opportunity to pick up the maintainer role and if that doesn't happen it should be removed.
A package should never be promoted to stable without an active maintainer who can make proper decisions about the impact this will have. Users should be able to become maintainers but they certainly shouldn't be able to just trigger such a move.
Regards, Dennis
On Fri, 07 Dec 2012 13:49:56 -0700 Dmitry Makovey dmitry@athabascau.ca wrote:
On 12/06/2012 06:23 PM, Joe Julian wrote:
However many intermediate repos we put in place, these unstable updates *have* to be allowed to go into epel-stable eventually. Otherwise, we put epel-stable users at risk for unpatched security flaws.
My point is, we already do. If an admin has to lock their packages to specific versions to keep their system working, then they are not going to be getting security updates.
sounds to me that there needs to be a clean procedure on promoting from testing to stable.
We have such a process in the karma process in bodhi. ;)
My opinion would be to let the users trigger that in cases where developers are busy with other things. So if we have foo-1.x.rpm in epel-stable, and foo-2.y.rpm in epel-testing and I, as a user see that it fixes bug/vulnerability/deprecates/etc. foo-1.x.rpm, I would:
- submit request for promotion from testing to stable,
- ...
- profit?
#2 can go as "need X votes in bugzilla" or "need N confirmations from users" something tangible and simple to follow for all involved.
Currently it's 2 weeks in testing or +3 karma.
In practice I almost never see anything get +3 karma, which shows that we have few testers. Also, seldom do things get -3 karma. ;(
kevin
On Wed, Nov 21, 2012 at 1:21 PM, Stephen John Smoogen smooge@gmail.comwrote:
OK from the various problems with various packages and the needs of packaging groups for a faster place for development and users for a more stable and knowing release cycle.. I would like to open the floor to what we can do to make EPEL more useful to both groups as best as possible with the goal that the proposals are finalized by FUDcon Lawrence and work on them completed within 6 months.
- Formalize what EPEL does and how it does it.
- Who gets to decide about updates
- How do we update major items (regularly after a RHEL release? after
a Fedora release?)
- How do we say "we can't support this architecture/release" anymore?
- Make sure it is documented what the Fedora Build System can do for
us and what it can't.
- Repotags (yes/no)
- Multiple channels for devel, testing, stable, old (yes/no)?
- Building for PPC/etc architectures when we don't have systems anymore?
So, since there have been several paths dicussed here I, but over a week ago was the last point I figured I'd poke the bear.
Several ideas have been discussed, there don't seem to be any general consensuses forming. Where do we go from here?
-greg
On Fri, 14 Dec 2012 09:25:29 -0600 Greg Swift gregswift@gmail.com wrote:
So, since there have been several paths dicussed here I, but over a week ago was the last point I figured I'd poke the bear.
Several ideas have been discussed, there don't seem to be any general consensuses forming. Where do we go from here?
I was hoping we would try and get interested folks together in person and on IRC at fudcon lawerence time and see if we could hash out the various ideas and reach some consensus.
I've personally not even had time to look carefully through the thread. Many of us are busy trying to get Fedora 18 out the door. ;)
Hopefully I will have some time over the holidays to look at all the ideas and see if any of them look like the way to go...
kevin
So, I have added a proposed session to the fudcon page for epel roundtable.
I don't know when it will get scheduled, but whenever it is, I will try and have some folks on irc (#epel) to help communicate the discussions back and forth for people unable to attend.
One thing that would be very helpful IMHO, would be if someone could gather the various ideas in this thread and summarize them on a wiki page or email. I can try and do this if no one else can.
Hopefully at fudcon we can hash out some proposals to in turn bring back to the list and see if we can reach consensus.
Sorry this whole process is taking so long...
kevin
It does not look like i can attend, but I will try to be on IRC at the time.
I'll also see if i can get sometime to work on the doc. On Jan 5, 2013 1:57 PM, "Kevin Fenzi" kevin@scrye.com wrote:
So, I have added a proposed session to the fudcon page for epel roundtable.
I don't know when it will get scheduled, but whenever it is, I will try and have some folks on irc (#epel) to help communicate the discussions back and forth for people unable to attend.
One thing that would be very helpful IMHO, would be if someone could gather the various ideas in this thread and summarize them on a wiki page or email. I can try and do this if no one else can.
Hopefully at fudcon we can hash out some proposals to in turn bring back to the list and see if we can reach consensus.
Sorry this whole process is taking so long...
kevin
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Sat, Jan 5, 2013 at 1:56 PM, Kevin Fenzi kevin@scrye.com wrote:
So, I have added a proposed session to the fudcon page for epel roundtable.
I don't know when it will get scheduled, but whenever it is, I will try and have some folks on irc (#epel) to help communicate the discussions back and forth for people unable to attend.
One thing that would be very helpful IMHO, would be if someone could gather the various ideas in this thread and summarize them on a wiki page or email. I can try and do this if no one else can.
Hopefully at fudcon we can hash out some proposals to in turn bring back to the list and see if we can reach consensus.
Sorry this whole process is taking so long...
So I did start a wiki page. It needs more work but, meh.. the ball is rolling.
On Tue, 8 Jan 2013 22:38:37 -0600 Greg Swift gregswift@gmail.com wrote:
On Sat, Jan 5, 2013 at 1:56 PM, Kevin Fenzi kevin@scrye.com wrote:
So, I have added a proposed session to the fudcon page for epel roundtable.
I don't know when it will get scheduled, but whenever it is, I will try and have some folks on irc (#epel) to help communicate the discussions back and forth for people unable to attend.
One thing that would be very helpful IMHO, would be if someone could gather the various ideas in this thread and summarize them on a wiki page or email. I can try and do this if no one else can.
Hopefully at fudcon we can hash out some proposals to in turn bring back to the list and see if we can reach consensus.
Sorry this whole process is taking so long...
So I did start a wiki page. It needs more work but, meh.. the ball is rolling.
Thanks!
I'm going to try and add some things there.
kevin
epel-devel@lists.fedoraproject.org
-
Dennis Jacobfeuerborn -
Dmitry Makovey -
Greg Swift -
inode0 -
Jan Pazdziora -
Joe Julian -
Ken Dreyer -
Kevin Fenzi -
Matthew Miller -
Matthias Runge -
Michael Stahnke -
Stephen John Smoogen -
Tomáš Smetana -
Troy Dawson