FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 02-07-2012, 10:09 PM
Ken Dreyer
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On Tue, Feb 7, 2012 at 3:57 PM, Bill McGonigle <bill@bfccomputing.com> wrote:
> But that's just off the top of my head - others probably have better
> ideas.

I appreciated Todd's approach with Puppet when that went from 0.25 to
2.6. Put it in updates-testing, and set the karma threshold really
high (in that case, 10). It's clear to me as a sysadmin that 2.6 is
coming down the line at some point, so I have an easy way to test when
it's convenient to me, and I can provide feedback in Bodhi. Can we
take that approach with other packages?

- Ken

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-07-2012, 10:22 PM
Xavier Bachelot
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On 02/08/2012 12:09 AM, Ken Dreyer wrote:
> On Tue, Feb 7, 2012 at 3:57 PM, Bill McGonigle <bill@bfccomputing.com> wrote:
>> But that's just off the top of my head - others probably have better
>> ideas.
>
> I appreciated Todd's approach with Puppet when that went from 0.25 to
> 2.6. Put it in updates-testing, and set the karma threshold really
> high (in that case, 10). It's clear to me as a sysadmin that 2.6 is
> coming down the line at some point, so I have an easy way to test when
> it's convenient to me, and I can provide feedback in Bodhi. Can we
> take that approach with other packages?
>
Puppet 2.6 is a bit special, as upstream has been extra careful not to
break compatibility from 0.25 to 2.6. And speaking of puppet, the update
from 0.24 to 0.25 not so long ago was a way much bumpier ride, at least
at my shop.

Don't get me wrong, I'm not saying the pupet update wasn't handled
right, and I too like the long grace period in updates-testing, but that
is already a stretch in the EPEL policy, so it might need to be adjusted.

The parallel installable packages can be convenient and easy to do in
some cases, but that will definitely not be true in any case. I think
this approach was already used for mediawiki and looked doable for
bugzilla too. This is probably more in line with the current 'no
disruptive upgrade policy'. However, I'm not sure if the retirement
policy for such packages was discussed and/or documented.

Regards,
Xavier

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-08-2012, 02:21 AM
Stephen John Smoogen
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On 7 February 2012 15:57, Bill McGonigle <bill@bfccomputing.com> wrote:
> On 02/01/2012 11:52 AM, Adam Miller wrote:
>> just that we continue along with
>> challenges we face today
>
> 'Just' is always tricky in these situations.
>
> I've been chatting with the Bugzilla packager on Bugzilla ('sup dog)
> about this, and I think it's worth talking about policy.
>
> EPEL6 currently ships Bugzilla 3.4, a branch that's about to become
> abandoned upstream. ¬*Xavier has been doing backports of security fixes
> to 3.2 (EPEL5) and could conceivably do this for 3.4 for a while, but
> doing this for the next 8 years is a tall order.
>
> The problem with the backports approach is that backporting difficulty
> doesn't scale linearly. ¬*Backporting a patch at year 1 is probably
> pretty easy - at year 10 it could be a major project.
>
> I think it's possible that the current EPEL policy may have been
> flirting with the edge of what is possible with volunteers and adding a
> significant time extension to that could push it over. ¬*Redhat has
> decided that it will pay its employees to make this happen for their
> [smaller] set of packages. ¬*I don't think it necessarily follows that
> this is the right decision for EPEL.
>
> In the case of Bugzilla, EPEL policy, as I understand it, precludes the
> rebasing of 3.4 to 3.6, 4.0, or 4.2 branches because upgrade
> compatibility isn't trivially guaranteed. ¬*The standard case would be
> satisfied by running the checksetup.pl script on upgrade, but certain
> extensions and customizations might cause that to fail.
>
> Xavier has entertained the idea of having a bugzilla36, bugzilla40, or
> bugzilla42 package for those seeking features, but that raises questions
> of usability 'yum install bugzilla??' and perhaps eventual abandonment
> of the 3.4 'bugzilla' package.
>

What I am doing with mediawiki is similar... and when mediawiki118
gets through a review process, 114,115 and 116 will be put in the
"goodbye" pile. Dealing with

yum install mediawiki

is a problem but I have come to the conclusion that having people at
least doing a "yum list mediawiki*" to help show what is available is
what I am aiming for.


--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"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
 
Old 02-09-2012, 01:46 AM
Kevin Fenzi
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

I think the thing to realize here is: we are only human and
volunteers, so don't expect miracles.

I would say the progression should be something like:

* Keep maintaining the major version until you no longer are able to
backport or fix issues or security. In that case, move to...

* Look at seeing if there is some way you can do the major version
upgrade in a way that works with rpm and is seemless for the end
user. Discuss on this list and see if you can come up with
something. If you can, make a lot of noise and announce and then do
the upgrade.

* If you can't do a seemless upgrade, you move on to parallel installs
like we are doing with mediawiki. Announce and try and get people to
realize the flow and that they need to upgrade.

* Finally, if there's just no way, retire the package and let everyone
know it's not possible to maintain.

At almost every step I think it's good to communicate to the list and
see if others have some way forward and also to let users who search
for info find out about your package.

So, I don't think there's any hard and fast rules that can never be
broken, but a progression where we try hard to avoid the next step.

Just my 2 cents.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-09-2012, 02:00 AM
Bill McGonigle
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On 02/08/2012 09:46 PM, Kevin Fenzi wrote:
> * If you can't do a seemless upgrade, you move on to parallel installs
> like we are doing with mediawiki. Announce and try and get people to
> realize the flow and that they need to upgrade.

I like the general outline, though the 'announce' part might be a bit
tricky. The biggest risk would be that people think they're getting
updates to their core package when they're not.

Several ideas that involve writing code came to mind, but the easiest
might be to do one more release of the base package and drop a cron.d
file in that tells root every day that he's running an maintained
package. It won't get everybody but most conscientious admins watch
their cron output (and could easily turn it off if they decide to stay
with the base package). EPEL could decide on a standard template to use.

Perhaps there's a better way to get word out to users?

I'm kinda wishing rpm could handle concurrent versions now...

-Bill


--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill@bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-09-2012, 07:42 AM
Xavier Bachelot
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On 02/09/2012 04:00 AM, Bill McGonigle wrote:

On 02/08/2012 09:46 PM, Kevin Fenzi wrote:

* If you can't do a seemless upgrade, you move on to parallel installs
like we are doing with mediawiki. Announce and try and get people to
realize the flow and that they need to upgrade.


I like the general outline, though the 'announce' part might be a bit
tricky. The biggest risk would be that people think they're getting
updates to their core package when they're not.

I like that too, and think it would be nice to have such a comprehensive
list somewhere in the wiki. I also fear that the announce mails might
miss their target and something involving yum would seem better to me.
See below.



Several ideas that involve writing code came to mind, but the easiest
might be to do one more release of the base package and drop a cron.d
file in that tells root every day that he's running an maintained
package. It won't get everybody but most conscientious admins watch
their cron output (and could easily turn it off if they decide to stay
with the base package). EPEL could decide on a standard template to use.

Perhaps there's a better way to get word out to users?

Rather than a cron mail that could easily get lost, just like the
announce mails, would there be any way to maintain a list of
discontinued packages in the repo or repodata and have a yum plugin
check against this list. I have no idea if it is at all possible to do
that, I don't know what yum plugins are able to do or not, and how
convenient/feasible it would do have such a list in the repo or repodatas.


Regards,
Xavier

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-09-2012, 03:39 PM
Kevin Fenzi
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On Wed, 08 Feb 2012 22:00:03 -0500
Bill McGonigle <bill@bfccomputing.com> wrote:

> On 02/08/2012 09:46 PM, Kevin Fenzi wrote:
> > * If you can't do a seemless upgrade, you move on to parallel
> > installs like we are doing with mediawiki. Announce and try and get
> > people to realize the flow and that they need to upgrade.
>
> I like the general outline, though the 'announce' part might be a bit
> tricky. The biggest risk would be that people think they're getting
> updates to their core package when they're not.

Yeah. Thats one reason I think it's important to discuss any such cases
here on this list (so they show up in a google search) and in
epel-announce (so they show up if someone searches there).

> Several ideas that involve writing code came to mind, but the easiest
> might be to do one more release of the base package and drop a cron.d
> file in that tells root every day that he's running an maintained
> package. It won't get everybody but most conscientious admins watch
> their cron output (and could easily turn it off if they decide to stay
> with the base package). EPEL could decide on a standard template to
> use.

I suppose, but some people may dislike being bothered.

> Perhaps there's a better way to get word out to users?

Not sure, but open to ideas.

> I'm kinda wishing rpm could handle concurrent versions now...
>
> -Bill

kevin

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-09-2012, 03:47 PM
Kevin Fenzi
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On Thu, 09 Feb 2012 09:42:06 +0100
Xavier Bachelot <xavier@bachelot.org> wrote:

> On 02/09/2012 04:00 AM, Bill McGonigle wrote:
> > On 02/08/2012 09:46 PM, Kevin Fenzi wrote:
> >> * If you can't do a seemless upgrade, you move on to parallel
> >> installs like we are doing with mediawiki. Announce and try and
> >> get people to realize the flow and that they need to upgrade.
> >
> > I like the general outline, though the 'announce' part might be a
> > bit tricky. The biggest risk would be that people think they're
> > getting updates to their core package when they're not.
> >
> I like that too, and think it would be nice to have such a
> comprehensive list somewhere in the wiki. I also fear that the
> announce mails might miss their target and something involving yum
> would seem better to me. See below.

Yeah, a wiki list at least would be good.

> Rather than a cron mail that could easily get lost, just like the
> announce mails, would there be any way to maintain a list of
> discontinued packages in the repo or repodata and have a yum plugin
> check against this list. I have no idea if it is at all possible to
> do that, I don't know what yum plugins are able to do or not, and how
> convenient/feasible it would do have such a list in the repo or
> repodatas.

Well, we could ship a package that removes them, or updates to the
epel-release that conflicts, but I would not really like that
personally. That forces things to be removed when it's not really
giving people the choice of running the old thing still. (Perhaps
internally where security doesn't matter so much to them).

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-09-2012, 04:43 PM
Stephen John Smoogen
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On 9 February 2012 09:47, Kevin Fenzi <kevin@scrye.com> wrote:
> On Thu, 09 Feb 2012 09:42:06 +0100
> Xavier Bachelot <xavier@bachelot.org> wrote:
>

> Well, we could ship a package that removes them, or updates to the
> epel-release that conflicts, but I would not really like that
> personally. That forces things to be removed when it's not really
> giving people the choice of running the old thing still. (Perhaps
> internally where security doesn't matter so much to them).
>

How about the following:

XXX-replaceble (requires the latest package and installs that)
XXXversionnumber (the one that is packaged up.)

When a package is going to be abandoned (like I did with mediawiki114)
one should put a last package with the same contents as the last one
and a doc file (and change to %description) saying "This package is
dead and abandonned. It is no longer supported by upstream and/or
EPEL. You are free to use this package as long as you like, but you
are the sole responsible party." Or some such thing.

If you install XXX-replaceable it upgrades to the latest version as
needed. If you pull in the XXXversionnumber then you stay on that.




--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"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
 
Old 02-09-2012, 04:46 PM
Stephen John Smoogen
 
Default Long-term package versions (RHEL 5+ extended to 10 years until EOL)

On 8 February 2012 20:00, Bill McGonigle <bill@bfccomputing.com> wrote:
> On 02/08/2012 09:46 PM, Kevin Fenzi wrote:
>> * If you can't do a seemless upgrade, you move on to parallel installs
>> ¬* like we are doing with mediawiki. Announce and try and get people to
>> ¬* realize the flow and that they need to upgrade.
t to users?
>
> I'm kinda wishing rpm could handle concurrent versions now...

One of the big issues with concurrent versions is that the software
itself most of the time does not deal with "concurrent" versions any
better than anything else. The hacks that were trying to be done in
mediawiki for the longest time sort of worked except when they didn't
and the basic word from upstream was "well we don't expect a person to
be able to run two different versions on the same system. Get another
and quit being crazy." The same with other software. Systems are
treated like ram these days by developers: It is cheap for them to
spin up extra boxes so it should be for you too (and if it isn't..
then you can try paying them to listen to you ).

> -Bill
>
>
> --
> Bill McGonigle, Owner
> BFC Computing, LLC
> http://bfccomputing.com/
> Telephone: +1.855.SW.LIBRE
> Email, IM, VOIP: bill@bfccomputing.com
> VCard: http://bfccomputing.com/vcard/bill.vcf
> Social networks: bill_mcgonigle/bill.mcgonigle
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list



--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"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
 

Thread Tools




All times are GMT. The time now is 08:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org