We need to work out format / policy for pkgs built and hosted in the CentOS Extras / CentOS Plus Testing area -> Stable repository.
One option is to move pkgs by Time-Default. Under this setup, once announced in the centos-devel list, after 14 days the pkgs are moved into the stable repositories. The time issue is arbitary, I feel 14 days is 'long enough'. If its too long we can shorten it to 7 days ? Would that give enough time to find major issues ?
Second option, would be to raise a bugs.centos.org issue for each pkg - and ask for feedback on the issue tracker. Moving the package from Testing to Stable would required a fixed number of positive responders. eg. 5 people need to confirm it works ?
Third option would be to leave it upto the packager / builder to decide when its ok to move things over from Testing -> Stable. However, in lots of cases, pkgers are busy. And to be honest, unless the pkger thinks its OK, the pkg would not be in Testing anyway. I prefer if other people were to be involved in the test process as well.
Suggestions ? Comments ?
On 12/7/05, Karanbir Singh mail-lists@karan.org wrote:
We need to work out format / policy for pkgs built and hosted in the CentOS Extras / CentOS Plus Testing area -> Stable repository.
One option is to move pkgs by Time-Default. Under this setup, once announced in the centos-devel list, after 14 days the pkgs are moved into the stable repositories. The time issue is arbitary, I feel 14 days is 'long enough'. If its too long we can shorten it to 7 days ? Would that give enough time to find major issues ?
Second option, would be to raise a bugs.centos.org issue for each pkg - and ask for feedback on the issue tracker. Moving the package from Testing to Stable would required a fixed number of positive responders. eg. 5 people need to confirm it works ?
Third option would be to leave it upto the packager / builder to decide when its ok to move things over from Testing -> Stable. However, in lots of cases, pkgers are busy. And to be honest, unless the pkger thinks its OK, the pkg would not be in Testing anyway. I prefer if other people were to be involved in the test process as well.
Suggestions ? Comments ?
Ideally some combination of time/feedback would seem to be the way to go. My fear is that if we require people to give feedback about something that's working, it won't happen and the package will rot in testing. 14 days is fine for moving things over I think, assuming no negative feedback is given.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
On Thu, 2005-12-08 at 02:37 +0000, Karanbir Singh wrote:
We need to work out format / policy for pkgs built and hosted in the CentOS Extras / CentOS Plus Testing area -> Stable repository.
One option is to move pkgs by Time-Default. Under this setup, once announced in the centos-devel list, after 14 days the pkgs are moved into the stable repositories. The time issue is arbitary, I feel 14 days is 'long enough'. If its too long we can shorten it to 7 days ? Would that give enough time to find major issues ?
Second option, would be to raise a bugs.centos.org issue for each pkg - and ask for feedback on the issue tracker. Moving the package from Testing to Stable would required a fixed number of positive responders. eg. 5 people need to confirm it works ?
Third option would be to leave it upto the packager / builder to decide when its ok to move things over from Testing -> Stable. However, in lots of cases, pkgers are busy. And to be honest, unless the pkger thinks its OK, the pkg would not be in Testing anyway. I prefer if other people were to be involved in the test process as well.
Fedora has been letting the packager set the standard but normally lets the testing period be 1 - 2 weeks.
Secondly - for preserving old packages we've been keeping the latest 2 versions of any package in the main repo - that's the standard extras is using now for repo pruning.
hope that helps.
-sv
Jim Perrin wrote:
Ideally some combination of time/feedback would seem to be the way to go. My fear is that if we require people to give feedback about something that's working, it won't happen and the package will rot in testing. 14 days is fine for moving things over I think, assuming no negative feedback is given.
+1
Or make that "+1/2" - no negative feedback doesn't mean, that someone tested it and the package didn't break his system, it could also mean that no one tested it. So there should be at least some form of positive feedback, just to make it clear that someone else than the packager *did* successfully install that package.
Ralph
On Thu, 2005-12-08 at 11:56 +0100, Ralph Angenendt wrote:
Jim Perrin wrote:
Ideally some combination of time/feedback would seem to be the way to go. My fear is that if we require people to give feedback about something that's working, it won't happen and the package will rot in testing. 14 days is fine for moving things over I think, assuming no negative feedback is given.
+1
Or make that "+1/2" - no negative feedback doesn't mean, that someone tested it and the package didn't break his system, it could also mean that no one tested it. So there should be at least some form of positive feedback, just to make it clear that someone else than the packager *did* successfully install that package.
I can see that as a problem too ... so there should be some kind of discussion on IRC in #centos-devel.
2 weeks seems OK for me for new programs that we haven't provided in the past.
For CentOS-4 at least, I think either Karanbir, Pasi, or I will be the one that moves it over to production ... and that one of us has personally tested it. I have zero problem with that for CentOS-4.
-- Johnny Hughes
Johnny Hughes wrote:
Ideally some combination of time/feedback would seem to be the way to go. My fear is that if we require people to give feedback about something that's working, it won't happen and the package will rot in testing.
I dont like the idea of time only moving to stable. if no one is eager enough to test the pkg - maybe we dont need it in the first place :) If we dont get any feedback for the pkg - maybe the developer who built it / pkg'ed it - should request specific feedback ?
Judging by the log's we seem to have picked up more than a few dozen users on the dev.centos.org repository... atleast a few of them should be willing to step forward and say ' it works / it breaks '.
Or make that "+1/2" - no negative feedback doesn't mean, that someone tested it and the package didn't break his system, it could also mean that no one tested it. So there should be at least some form of positive feedback, just to make it clear that someone else than the packager *did* successfully install that package.
install is easy to check for, as a part of the buildsystem here at my end, each rpm - once built is installed and any rpm + yum output is log'ed - if there is something out of the ordinary, the package gets held back and is not released anyway.
2 weeks seems OK for me for new programs that we haven't provided in the past.
I worry about the fact that even 1 loose pkg out there, can break a _lot_ of people's setup, we have a *lot* of people know using CentOSPLus and Extras is enabled by default .... Personally, I would be much happier if atleast a couple of people had the 'it works' feedback to provide before it gets moved over.
For CentOS-4 at least, I think either Karanbir, Pasi, or I will be the one that moves it over to production ... and that one of us has personally tested it. I have zero problem with that for CentOS-4.
Sounds good to me.
On Fri, 16 Dec 2005, Karanbir Singh wrote:
I dont like the idea of time only moving to stable. if no one is eager enough to test the pkg - maybe we dont need it in the first place :) If we dont get any feedback for the pkg - maybe the developer who built it / pkg'ed it - should request specific feedback ?
concur +1
I worry about the fact that even 1 loose pkg out there, can break a _lot_ of people's setup, we have a *lot* of people know using CentOSPLus and Extras is enabled by default .... Personally, I would be much happier if atleast a couple of people had the 'it works' feedback to provide before it gets moved over.
concur plus LOTS
cAos 1 had this happen with an innocent novice packager in cAos 1 that was not watched [closely enough as it turns out in hindsight], and whose work was not tested other than against a few packages; his work entered a yumable state, and it poisoned the entire distribution release.
The collateral damage which resulted essentially killed cAos-1 development; I took a couple of runs of trying to get a yum-able migration path out, but as Gnomish (/me turns to the side and spits) elements had some false cross- Requires/Provides into Python (/me repeats the prior action); as yum and Python are joined at the hip, it could not be solved.
The mess was so bad that the cAos group lost all momentum, and eventually walked away from that failed orphan. Just earlier this week, Greg had to maunally solve a injudicously kard-coded Requires/Provides pair, as a blocker had again slipped in [which also indicates a fault in the release protocol of not running a repocheck still exists].
While it may be acceptible to a bleeding edge distribution to experiment, it is so far from the Centos purposes, that I wonder if automatic promotion is ever worth the risk for a production distribution. I think not.
-- Russ Herrold
so can we all agree on the following :
All packages to dev.centos.org should be announced here on centos-devel@centos.org
We need 5 ( five ) 'it works' before its most to stable
At least 1 'it works' from each Arch the package is bing built for.
Packages for CentOS4, need to be built on the standard buildsystems building the [base] and [updates], when they are moved from dev.centos.org to mirror.centos.org
On Tue, 20 Dec 2005, R P Herrold wrote:
concur plus LOTS
ditto. I use centos for stability. period.
------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
-
Jim Perrin -
Jim Wildman -
Johnny Hughes -
Karanbir Singh -
R P Herrold -
Ralph Angenendt -
seth vidal