Re: [Mageia-dev] RFC: Opening Backports (once again...)
On Sunday, 11 December 2011 19:43:35 Florian Hubold wrote: \ Whatever the decision is, maybe we could tie this to some conditions: Only allow backports if there are near-zero security/critical bugs for the stable release or if there are no open bugs for the package in question? Well, my first question is, *who* is *responsible* for security updates? This is not specified in the updates policy (the role assigned to build the security update is named 'Maintainer (or any interested packager)', but who is responsible for checking that we have all applicable updates? In Mandriva, it was the responsibility of the security team (with cooperation from the maintainer in some cases). At some stage we also need to look at providing vulnerability data in a suitable format that supports automated validation (e.g. OVAL?), and a site able to browse advisories. Just some random crazy idea ... IMHO we should focus on security and bugfixes for the stable release, and there are currently too many security bugs open, some for a really long time, where nothing is happening for months, yet we still talk and concern about opening backports. FYI: the reason I have been slow on updates for Mageia is that I still have systems running Mandriva, precisely because the bacports situation has not been finalised, and I don't want to submit all missing packages in Mageia 1 to updates. Once backports is open, I can drop some Mandriva packages, and spend more time contributing to Mageia. So, you can't necessarily say that backports steals time from updates ... Regards, Buchan
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On Saturday, 10 December 2011 13:32:12 Michael Scherer wrote:
Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
Well, the backport issue ( ie :
- no garantee of keep the distribution upgradable
Backports will probably provide a better probability of upgradability than
3rd-party repos.
- no security )
No means to provide a security updates that has followed a QA process in the
event package version Z no longer builds on distribution with version X in
release and version Y in backports.
But, note that without backports, users who wanted version Y would either:
-Switch to a distro that has version Y (worse) - I would guess 20%
-Switch to using cauldron, and start contributing (better) - I would guess 5%
or less
-Use Cauldron package on stable release (worse) - I would guess about 30%
-Build package from source (worse) - I would guess about 20%
-Rebuild cauldron package on stable release (same) - I wold guess about 10%
-Keep version X (better) and eventually become upset about age of software
(worse) - I would guess about 15%
So, only one outcome would be better, one would be the same, and the other 3
outcomes would be worse, and probably be the majority of outcomes.
In the case where there is no problem with providing the update, backports is
superiour, and would provide a better outcome in every case.
Do we have any idea on how many packages this ever affected in Mandriva?
have also not been fixed, so that's rather unfair to
... ?
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1/package/{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
I thought the whole point of Backports was to provide a streamlined way to
provide newer versions of packages that already exist in Cauldron, with
minimal effort, to stable releases. This increases the incentive for users on
stable releases to contribute to Cauldron in some way, and doesn't increase
the burden on the maintainer significantly. There should be no need to have
distribution release-specific content in any of the packages.
In the rare case a package can't be provided like this, maybe it isn't a good
candidate for backports?
Then in practice, that mean having a 2nd/3rd distribution ( because
there is a separate 2nd svn branch, and a 3rd one for later ) and so
that's a big no for me. Having 2+ branchs is just asking for trouble
when they are not in sync ( and since keeping everything in sync
properly with svn is a pain if there is a divergence, this will not be
done ).
Worst, if we do like in mdv and propose 2 way of backporting ( submit
from cauldron, submit from a branch ), this will create a mess of having
some packages from cauldron, some from the branch, and people having no
way from knowing where does a package come from. This also make the
system harder to maintain and to follow, and rather impossible to script
properly.
So that's also to be avoided.
Having a separate branch where people can write also remove the only
incentive I have seen for backports, ie, wider testing of our packages,
because they may not really the same as in cauldron.
So here is what I propose :
- have X branchs, but do not let anyone commit on it, besides a system
user. When a package is submitted to cauldron, it is also copied to this
branch, ie, we make sure current is in sync. The same goes for version
N-1 being copied from N once a backported rpm have been submitted to be
used by people. Once a distribution is no longer supported, we close the
branch, and disable the sync.
- backports are only submitted from the branch, with separate
markrelease, tags, whatever. This let us have proper audit of backports,
and who did what.
- packagers still need to commit and submit on cauldron before any
backports. So we miss no fixes or anything by mistake. We also make sure
that cauldron is always the highest version possible, thus permitting at
least some form of upgrade. ( either stable to stable, provided
backports are used, or stable to cauldron ). And we also ensure that
backports are done first on the most recent stable version, for the same
reason ( ensure some form of upgrade path, as asked several time by
users ).
So, we have two copies of identical packages, that are always in sync, and can
never diverge.
What is the point then? Just to allow
Re: [Mageia-dev] RFC: Opening Backports (once again...)
[...] At some stage we also need to look at providing vulnerability data in a suitable format that supports automated validation (e.g. OVAL?), and a site able to browse advisories. If this means less work, and is relatively easy to do by package maintainers, then, this looks like quite a good idea. Just some random crazy idea ... IMHO we should focus on security and bugfixes for the stable release, and there are currently too many security bugs open, some for a really long time, where nothing is happening for months, yet we still talk and concern about opening backports. FYI: the reason I have been slow on updates for Mageia is that I still have systems running Mandriva, precisely because the bacports situation has not been finalised, and I don't want to submit all missing packages in Mageia 1 to updates. Once backports is open, I can drop some Mandriva packages, and spend more time contributing to Mageia. So, you can't necessarily say that backports steals time from updates ... interesting point of view...
Re: [Mageia-dev] RFC: Opening Backports (once again...)
martedì 3 gennaio 2012 alle 10:45, Buchan Milne ha scritto: -Build package from source (worse) - I would guess about 20% -Rebuild cauldron package on stable release (same) - I wold guess about 10% IMO you're very optimistic here :) I think this is true for expert users, so the ones who started developing in mageia, or some who would like to start contributing and his status is pending waiting mentors... Non expert users will probably switch to other distros... increasing your first percentage. But we should think also about the percentage of users that would like the backports, that should be interesting, i mean if the 3% want backports loosing that percentage could be not very interesting... and we could try to be better in 2... am i wrong? Angelo (who is in favour to open bp) signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] RFC: Opening Backports (once again...)
sabato 10 dicembre 2011 alle 17:09, Thomas Backlund ha scritto: Sorry, buth this wont work in reality... Consider this: version X in Mageia 1 version X+1 in Cauldron version X+1 gets backported. version X+2 uploaded in Cauldron version X+2 cant be backported (depends on updated libs/packages in Cauldron, and we dont backport libs that can break working setups) version X+1 in backports need to be fixed (security/maintenance fix) (here your logic breaks down, there is no place to fix it) And since we aim for quality backports, the maintainer may want to stay with version X+1 in backports even if X+2 could be backported if maintainer think X+2 isn't a good candidate for some reason. So, couldn't we consider backports in the same way as updates? The only difference is that they go into another branch, and they need to have a higher version than in updates and lower than cauldron. Tests and validations follow the same rules, if a backport is not validated won't be pushed. Is that more work for QA? unfortunately yes, but i do hope tests and validations can be done by more users interested in that update/backport. Why using backports instead of updates then? because for some reasons we -or maintainers- don't want to push as update a new version. I'm not really in favour of a strict release update, we have already pacakges not doing that (leaf ones, or those that are a pain to patch like ff for instance,...). In such a way backports is not going to be seen as a potential breakage of the system, but as a part of distro life. A problem i can see though is if a maintainer decides that a version that has been backported can become an update, even if it can be managed by working on release version, that update is svn and HD room effect... Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Op zondag 11 december 2011 11:41:02 schreef Angelo Naselli: sabato 10 dicembre 2011 alle 17:09, Thomas Backlund ha scritto: Sorry, buth this wont work in reality... Consider this: version X in Mageia 1 version X+1 in Cauldron version X+1 gets backported. version X+2 uploaded in Cauldron version X+2 cant be backported (depends on updated libs/packages in Cauldron, and we dont backport libs that can break working setups) version X+1 in backports need to be fixed (security/maintenance fix) (here your logic breaks down, there is no place to fix it) And since we aim for quality backports, the maintainer may want to stay with version X+1 in backports even if X+2 could be backported if maintainer think X+2 isn't a good candidate for some reason. So, couldn't we consider backports in the same way as updates? The only difference is that they go into another branch, and they need to have a higher version than in updates and lower than cauldron. Tests and validations follow the same rules, if a backport is not validated won't be pushed. Is that more work for QA? unfortunately yes, but i do hope tests and validations can be done by more users interested in that update/backport. Why using backports instead of updates then? because for some reasons we -or maintainers- don't want to push as update a new version. I'm not really in favour of a strict release update, we have already pacakges not doing that (leaf ones, or those that are a pain to patch like ff for instance,...). In such a way backports is not going to be seen as a potential breakage of the system, but as a part of distro life. A problem i can see though is if a maintainer decides that a version that has been backported can become an update, even if it can be managed by working on release version, that update is svn and HD room effect... Angelo you can have new version as updates. backporting is the addition of new features and thus the possibility of new bugs, even with QA, you can't completely get the same level of stability from updates, as you get from backports... but that's fine. it doesn't need to be, it's not enabled by default, it'd be nice if those work well. what we really want is for backports to be suggested in rpmdrake on a case by case basis. since fixing bugs is more important that adding new features and some people do updates, but don't want any risk, it's completely valid that they are separate. i just vote that we make a svn backports branch, (NOT a separate repos, it'd be nice if we can just branch it, which doesn't use any extra disk space), for some packages it means we can add a patch on backports to make it work for mga1 specifically and still merge patches from cauldron into backports if we want (or wherever we branch from) we should however keep matches close at a hand, in case people do weird things, some automated checks could be done and possibly mailed somewhere to show that suspicious activity is going on... if it's tmb, we know we can ignore it then. i think this is by far the most flexible solution, and we should try to keep our level of maintainers high, but informing them of where it can go wrong, what they should look for... just my 0.02€
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Am 11.12.2011 17:11, schrieb Maarten Vanraes: Op zondag 11 december 2011 11:41:02 schreef Angelo Naselli: sabato 10 dicembre 2011 alle 17:09, Thomas Backlund ha scritto: Sorry, buth this wont work in reality... Consider this: version X in Mageia 1 version X+1 in Cauldron version X+1 gets backported. version X+2 uploaded in Cauldron version X+2 cant be backported (depends on updated libs/packages in Cauldron, and we dont backport libs that can break working setups) version X+1 in backports need to be fixed (security/maintenance fix) (here your logic breaks down, there is no place to fix it) And since we aim for quality backports, the maintainer may want to stay with version X+1 in backports even if X+2 could be backported if maintainer think X+2 isn't a good candidate for some reason. So, couldn't we consider backports in the same way as updates? The only difference is that they go into another branch, and they need to have a higher version than in updates and lower than cauldron. Tests and validations follow the same rules, if a backport is not validated won't be pushed. Is that more work for QA? unfortunately yes, but i do hope tests and validations can be done by more users interested in that update/backport. Why using backports instead of updates then? because for some reasons we -or maintainers- don't want to push as update a new version. I'm not really in favour of a strict release update, we have already pacakges not doing that (leaf ones, or those that are a pain to patch like ff for instance,...). In such a way backports is not going to be seen as a potential breakage of the system, but as a part of distro life. A problem i can see though is if a maintainer decides that a version that has been backported can become an update, even if it can be managed by working on release version, that update is svn and HD room effect... Angelo you can have new version as updates. backporting is the addition of new features and thus the possibility of new bugs, even with QA, you can't completely get the same level of stability from updates, as you get from backports... but that's fine. it doesn't need to be, it's not enabled by default, it'd be nice if those work well. what we really want is for backports to be suggested in rpmdrake on a case by case basis. since fixing bugs is more important that adding new features and some people do updates, but don't want any risk, it's completely valid that they are separate. i just vote that we make a svn backports branch, (NOT a separate repos, it'd be nice if we can just branch it, which doesn't use any extra disk space), for some packages it means we can add a patch on backports to make it work for mga1 specifically and still merge patches from cauldron into backports if we want (or wherever we branch from) we should however keep matches close at a hand, in case people do weird things, some automated checks could be done and possibly mailed somewhere to show that suspicious activity is going on... if it's tmb, we know we can ignore it then. i think this is by far the most flexible solution, and we should try to keep our level of maintainers high, but informing them of where it can go wrong, what they should look for... just my 0.02€ Whatever the decision is, maybe we could tie this to some conditions: Only allow backports if there are near-zero security/critical bugs for the stable release or if there are no open bugs for the package in question? Just some random crazy idea ... IMHO we should focus on security and bugfixes for the stable release, and there are currently too many security bugs open, some for a really long time, where nothing is happening for months, yet we still talk and concern about opening backports.
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Op zondag 11 december 2011 18:43:35 schreef Florian Hubold: [...] just my 0.02€ Whatever the decision is, maybe we could tie this to some conditions: Only allow backports if there are near-zero security/critical bugs for the stable release or if there are no open bugs for the package in question? Just some random crazy idea ... IMHO we should focus on security and bugfixes for the stable release, and there are currently too many security bugs open, some for a really long time, where nothing is happening for months, yet we still talk and concern about opening backports. even thought that is true, the reason there is so much talk and bikeshedding on this, is because it's still not there (and also users ask for it (they also ask for updates, but those are other users :-) )) if it had been there, there would not have been such time loss with it and several discussions. personally, i think the best thing is to have a quick resolv...
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Le mardi 06 décembre 2011 à 01:29 +0200, Anssi Hannula a écrit : The biggest problem for me is that it is really difficult to test any changes, one'd need a mockup of the whole buildsystem... and I don't want to propose any patches blind :) 2 vm + setup of puppet should be able to fully replicate the configuration. Despites being seen as a hot skill ( http://siliconangle.com/blog/2011/10/31/puppet-and-hadoop-among-the-hottest-it-skills/ ), I am rather surprised that no one take the opportunity to learn it and to help. -- Michael Scherer
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
Well, the backport issue ( ie :
- no garantee of keep the distribution upgradable
- no security )
have also not been fixed, so that's rather unfair to
And at current rate we will probably release Mageia infinity
before backports is opened.
It has been delayed because of needed infrastructure changes,
something no-one have had time to do so far...
I know there is only some coding missing and someone should
do it, buth truthfully there are only a few that knows the
code used in the buildsystem enough to actually make it happend,
and they are already othervise busy or overloaded...
(this is no rant against them, as all here are using their
personal free time to help out)
And to be honest I dont see that changing anytime soon...
Then we have a bigger problem to solve.
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1/package/{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
Then in practice, that mean having a 2nd/3rd distribution ( because
there is a separate 2nd svn branch, and a 3rd one for later ) and so
that's a big no for me. Having 2+ branchs is just asking for trouble
when they are not in sync ( and since keeping everything in sync
properly with svn is a pain if there is a divergence, this will not be
done ).
Worst, if we do like in mdv and propose 2 way of backporting ( submit
from cauldron, submit from a branch ), this will create a mess of having
some packages from cauldron, some from the branch, and people having no
way from knowing where does a package come from. This also make the
system harder to maintain and to follow, and rather impossible to script
properly.
So that's also to be avoided.
Having a separate branch where people can write also remove the only
incentive I have seen for backports, ie, wider testing of our packages,
because they may not really the same as in cauldron.
So here is what I propose :
- have X branchs, but do not let anyone commit on it, besides a system
user. When a package is submitted to cauldron, it is also copied to this
branch, ie, we make sure current is in sync. The same goes for version
N-1 being copied from N once a backported rpm have been submitted to be
used by people. Once a distribution is no longer supported, we close the
branch, and disable the sync.
- backports are only submitted from the branch, with separate
markrelease, tags, whatever. This let us have proper audit of backports,
and who did what.
- packagers still need to commit and submit on cauldron before any
backports. So we miss no fixes or anything by mistake. We also make sure
that cauldron is always the highest version possible, thus permitting at
least some form of upgrade. ( either stable to stable, provided
backports are used, or stable to cauldron ). And we also ensure that
backports are done first on the most recent stable version, for the same
reason ( ensure some form of upgrade path, as asked several time by
users ).
And we can still use %ifdef if a need arise for a different spec between
distribution versions. While that make spec less readable, that's more
readable than having forked specs 2 or 3 times.
This requires :
- 1 youri action to copy the package to current backport branch ( can be
done based on the markrelease action and the others )
- 1 svn configuration to prevent people from writing directly there ( or
just say to not do it, and burn people who do it )
- youri config to let people submit from backports to backports_testing.
--
Michael Scherer
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Op zaterdag 10 december 2011 12:32:12 schreef Michael Scherer: Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit : Now, here comes the question about backports once again. We are now 6+ months into Mageia 1, and we are nowhere closer to opening backports that we were at Mageia 1 release time. Because of that there are 3rdparty repos popping up everywhere..., something we hoped to avoid atleast partly when starting this project. [...] And to be honest I dont see that changing anytime soon... Then we have a bigger problem to solve. This is likely correct, i think we have shortage of people in various parts, but perhaps sysadmin (which is arguably the most important team), has not enough active people to follow up all the issues (or they are busy with other teams). because other teams are counting on sysadmin team and even though it's all on svn, it's not that easy (i think; at least for me) to learn this system and put some patches for sysadmin to follow, perhaps sysadmin team should grow a bit more people. [...] Using a separate branch is also a cleaner way of providing backports, and makes it easy to separate changes needed only for Cauldron (or backports). Then in practice, that mean having a 2nd/3rd distribution ( because there is a separate 2nd svn branch, and a 3rd one for later ) and so that's a big no for me. Having 2+ branchs is just asking for trouble when they are not in sync ( and since keeping everything in sync properly with svn is a pain if there is a divergence, this will not be done ). Worst, if we do like in mdv and propose 2 way of backporting ( submit from cauldron, submit from a branch ), this will create a mess of having some packages from cauldron, some from the branch, and people having no way from knowing where does a package come from. This also make the system harder to maintain and to follow, and rather impossible to script properly. So that's also to be avoided. Having a separate branch where people can write also remove the only incentive I have seen for backports, ie, wider testing of our packages, because they may not really the same as in cauldron. I think there are more incentives than just that for backports, at least imho. plus, if the problem is you don't know where it's from, perhaps we should fix that problem instead of having an arguably less flexible solution. also, iirc, when branching svn, afaik it mentions where it's been branched from? So here is what I propose : - have X branchs, but do not let anyone commit on it, besides a system user. When a package is submitted to cauldron, it is also copied to this branch, ie, we make sure current is in sync. The same goes for version N-1 being copied from N once a backported rpm have been submitted to be used by people. Once a distribution is no longer supported, we close the branch, and disable the sync. - backports are only submitted from the branch, with separate markrelease, tags, whatever. This let us have proper audit of backports, and who did what. - packagers still need to commit and submit on cauldron before any backports. So we miss no fixes or anything by mistake. We also make sure that cauldron is always the highest version possible, thus permitting at least some form of upgrade. ( either stable to stable, provided backports are used, or stable to cauldron ). And we also ensure that backports are done first on the most recent stable version, for the same reason ( ensure some form of upgrade path, as asked several time by users ). And we can still use %ifdef if a need arise for a different spec between distribution versions. While that make spec less readable, that's more readable than having forked specs 2 or 3 times. This requires : - 1 youri action to copy the package to current backport branch ( can be done based on the markrelease action and the others ) - 1 svn configuration to prevent people from writing directly there ( or just say to not do it, and burn people who do it ) - youri config to let people submit from backports to backports_testing. for me this solution would be ok, but iirc tmb requires for kernel a bit more flexibility? and tbh, having a more dirty spec file is not something i'd wish for... but, even if this is a nice solution, we still have the problem listed above that we'd get backports since before mageia1 and it's still not here? since it's also not the priority (updates are more important) what chances do we have of actually having backports before mga2?
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Michael Scherer skrev 10.12.2011 13:32:
Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
Well, the backport issue ( ie :
- no garantee of keep the distribution upgradable
Policy is to always keep Cauldron with atleast higher release,
so next release will be ok.
I guess when we have 2 releases we must extend the policy to
state that if you backport to Mageia 1 you also must backport
to Mageia 2 in order to keep upgrading fully possible.
- no security )
Well, that's the same as with current stable relase,
maintainer/backporter submits security fixes to backports_testing
QA validates, update gets pushed.
have also not been fixed, so that's rather unfair to
And at current rate we will probably release Mageia infinity
before backports is opened.
It has been delayed because of needed infrastructure changes,
something no-one have had time to do so far...
I know there is only some coding missing and someone should
do it, buth truthfully there are only a few that knows the
code used in the buildsystem enough to actually make it happend,
and they are already othervise busy or overloaded...
(this is no rant against them, as all here are using their
personal free time to help out)
And to be honest I dont see that changing anytime soon...
Then we have a bigger problem to solve.
Yep, no argument here
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1/package/{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
Then in practice, that mean having a 2nd/3rd distribution ( because
there is a separate 2nd svn branch, and a 3rd one for later ) and so
that's a big no for me. Having 2+ branchs is just asking for trouble
when they are not in sync ( and since keeping everything in sync
properly with svn is a pain if there is a divergence, this will not be
done ).
Worst, if we do like in mdv and propose 2 way of backporting ( submit
from cauldron, submit from a branch ), this will create a mess of having
some packages from cauldron, some from the branch, and people having no
way from knowing where does a package come from. This also make the
system harder to maintain and to follow, and rather impossible to script
properly.
So that's also to be avoided.
Well, branching is needed, regardless if it's done in a whole separate
branch as I suggested, or in a branch per package when needed.
Having a separate branch where people can write also remove the only
incentive I have seen for backports, ie, wider testing of our packages,
because they may not really the same as in cauldron.
It cant always be the same in cauldron and backports.
So here is what I propose :
- have X branchs, but do not let anyone commit on it, besides a system
user. When a package is submitted to cauldron, it is also copied to this
branch, ie, we make sure current is in sync. The same goes for version
N-1 being copied from N once a backported rpm have been submitted to be
used by people. Once a distribution is no longer supported, we close the
branch, and disable the sync.
If you cant commit to the branch, it's useless.
- backports are only submitted from the branch, with separate
markrelease, tags, whatever. This let us have proper audit of backports,
and who did what.
the same auditing is available in any branch or cauldron.
- packagers still need to commit and submit on cauldron before any
backports. So we miss no fixes or anything by mistake. We also make sure
that cauldron is always the highest version possible, thus permitting at
least some form of upgrade. ( either stable to stable, provided
backports are used, or stable to cauldron ). And we also ensure that
backports are done first on the most recent stable version, for the same
reason ( ensure some form of upgrade path, as asked several time by
users ).
Sorry, buth this wont work in reality...
Consider this:
version X in Mageia 1
version X+1 in Cauldron
version X+1 gets backported.
version X+2 uploaded in Cauldron
version X+2 cant be backported (depends on updated libs/packages in
Cauldron, and we dont backport libs that can break working setups)
version X+1 in backports need to be fixed (security/maintenance fix)
(here your logic breaks down, there is no place to fix it)
And since we aim for quality backports, the maintainer may want to
stay with version X+1 in backports even if X+2 could be backported
if maintainer
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Anssi Hannula skrev 6.12.2011 01:29:
On 06.12.2011 00:56, Thomas Backlund wrote:
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
And at current rate we will probably release Mageia infinity
before backports is opened.
It has been delayed because of needed infrastructure changes,
something no-one have had time to do so far...
I know there is only some coding missing and someone should
do it, buth truthfully there are only a few that knows the
code used in the buildsystem enough to actually make it happend,
and they are already othervise busy or overloaded...
(this is no rant against them, as all here are using their
personal free time to help out)
The biggest problem for me is that it is really difficult to test any
changes, one'd need a mockup of the whole buildsystem... and I don't
want to propose any patches blind :)
And to be honest I dont see that changing anytime soon...
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1/package/{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
Hm, how does this help with enabling backports (i.e. compared to simply
using cauldron repo)?
It was suggested to prevent direct submissions from cauldron as
current BS is not capable of blocking cauldron - updates_testing
if we add cauldron to supported url
So a separate backports branch would be created to work around this.
(yes I know you could do svn cp and then submit, but atleast it would
prevent submissions done by mistake)
And if we want to extend the checks, maybe mgarepo could be updated to
only allow submission to backports_testing from backports branch until
server side checking is in place. (the same connection could probably
be done between updates_testing and updates too)
Anyway, would the above branch work like this:
e.g. lets imagine I want to, in order:
1. provide foobar 1.1 to backports.
2. cauldron foobar upgraded to 1.2, some patches added, some removed,
and other changes
3. provide foobar 1.2 to backports
4. 1.3 to cauldron and backports
To backport foobar 1.1, I guess I'd simply do
svn copy svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
and then the submit command.
When time comes to provide foobar 1.2 to backports, the options are:
Option 1:
svn del svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
svn copy svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
and submit. Changelog is the same as in cauldron.
Option 2:
svn checkout \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar/current \
foobar
cd foobar svn merge -r prevrev:HEAD \
svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar/current
svn commit
# copy all the log entries from the cauldron interval to the log msg
and submit.
Note: results in broken changelogs unless one does manual
markreleases, but changelogs are already broken both in mga1 updates
and in cauldron (youri issue [1]). This is more notable here, though,
as backports happen generally more often multiple times than updates.
Repeat with 1.3.
Correct?
I guess this is up to the maintainer how he/she wants to maintain the
backports of his package as it can also be Option 3: maintain backports
branch separately (depending on package).
For example, for me I'd like to provide kernel-rt-3.0.x as backports,
but would probably not provide 3.2.x at all for Mageia 1.
(sidenote, kernel-rt is a little tricky here as it was available as
2.6.33 series in 2010.2, so it could go to updates. but since it
would also need backported nvidia/fglrx (if they work that is),
and the /proc/net/route info changed in 2.6.39 so it would break
network detection too, and version 3.* could break some scripts
checking for 2.*, so I'd rather submit it as a backport.)
[1] https://bugs.mageia.org/show_bug.cgi?id=2633
Yeah, this is another thing that needs to be fixed regardless of
what we do with backports. for now we have just disabled markrel
for updates so it does not mess up the changelogs even more.
--
Thomas
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On 07.12.2011 21:06, Thomas Backlund wrote: Anssi Hannula skrev 6.12.2011 01:29: [1] https://bugs.mageia.org/show_bug.cgi?id=2633 Yeah, this is another thing that needs to be fixed regardless of what we do with backports. for now we have just disabled markrel for updates so it does not mess up the changelogs even more. Ah, good. Has someone invalidated the old wrong mga1 update markreleases from cauldron mga2 tree, or shall I look into scripting it (or is someone already looking into it)? -- Anssi Hannula
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Anssi Hannula skrev 7.12.2011 21:37: On 07.12.2011 21:06, Thomas Backlund wrote: Anssi Hannula skrev 6.12.2011 01:29: [1] https://bugs.mageia.org/show_bug.cgi?id=2633 Yeah, this is another thing that needs to be fixed regardless of what we do with backports. for now we have just disabled markrel for updates so it does not mess up the changelogs even more. Ah, good. Has someone invalidated the old wrong mga1 update markreleases from cauldron mga2 tree, or shall I look into scripting it (or is someone already looking into it)? Nope, it's still not done, so if you can/want to sort it out, please do so. -- Thomas
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On 07.12.2011 21:39, Thomas Backlund wrote: Anssi Hannula skrev 7.12.2011 21:37: On 07.12.2011 21:06, Thomas Backlund wrote: Anssi Hannula skrev 6.12.2011 01:29: [1] https://bugs.mageia.org/show_bug.cgi?id=2633 Yeah, this is another thing that needs to be fixed regardless of what we do with backports. for now we have just disabled markrel for updates so it does not mess up the changelogs even more. Ah, good. Has someone invalidated the old wrong mga1 update markreleases from cauldron mga2 tree, or shall I look into scripting it (or is someone already looking into it)? Nope, it's still not done, so if you can/want to sort it out, please do so. I hate changelog breakage, so I'll do it :) -- Anssi Hannula
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On 07.12.2011 21:52, Anssi Hannula wrote: On 07.12.2011 21:39, Thomas Backlund wrote: Anssi Hannula skrev 7.12.2011 21:37: On 07.12.2011 21:06, Thomas Backlund wrote: Anssi Hannula skrev 6.12.2011 01:29: [1] https://bugs.mageia.org/show_bug.cgi?id=2633 Yeah, this is another thing that needs to be fixed regardless of what we do with backports. for now we have just disabled markrel for updates so it does not mess up the changelogs even more. Ah, good. Has someone invalidated the old wrong mga1 update markreleases from cauldron mga2 tree, or shall I look into scripting it (or is someone already looking into it)? Nope, it's still not done, so if you can/want to sort it out, please do so. I hate changelog breakage, so I'll do it :) Done (233 markrelease propsets and removed tags). -- Anssi Hannula
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Anssi Hannula skrev 8.12.2011 01:58: On 07.12.2011 21:52, Anssi Hannula wrote: On 07.12.2011 21:39, Thomas Backlund wrote: Anssi Hannula skrev 7.12.2011 21:37: On 07.12.2011 21:06, Thomas Backlund wrote: Anssi Hannula skrev 6.12.2011 01:29: [1] https://bugs.mageia.org/show_bug.cgi?id=2633 Yeah, this is another thing that needs to be fixed regardless of what we do with backports. for now we have just disabled markrel for updates so it does not mess up the changelogs even more. Ah, good. Has someone invalidated the old wrong mga1 update markreleases from cauldron mga2 tree, or shall I look into scripting it (or is someone already looking into it)? Nope, it's still not done, so if you can/want to sort it out, please do so. I hate changelog breakage, so I'll do it :) Done (233 markrelease propsets and removed tags). Great! Thanks for doing this! -- Thomas
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Le mardi 6 décembre 2011 00:29:03, Anssi Hannula a écrit : Using a separate branch is also a cleaner way of providing backports, and makes it easy to separate changes needed only for Cauldron (or backports). Hm, how does this help with enabling backports (i.e. compared to simply using cauldron repo)? The current system needs a rework to be able to accept packages submitted from cauldron to 1/backports_testing while forbidding submit from cauldron to 1/updates_testing Back in september I had proposed 2 solutions : - the current proposal from tmb, which I support (but which requires a change in the policy as it is currently defined) - allowing to submit anywhere from cauldron (and have QA verify that the packages have been submitted from the right branch, and burn publicly packagers who submit from cauldron to updates_testing) Both would require little tweaking to the build system.
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Op maandag 05 december 2011 23:56:25 schreef Thomas Backlund: [...] Using a separate branch is also a cleaner way of providing backports, and makes it easy to separate changes needed only for Cauldron (or backports). agreed
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On 06.12.2011 00:56, Thomas Backlund wrote:
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
And at current rate we will probably release Mageia infinity
before backports is opened.
It has been delayed because of needed infrastructure changes,
something no-one have had time to do so far...
I know there is only some coding missing and someone should
do it, buth truthfully there are only a few that knows the
code used in the buildsystem enough to actually make it happend,
and they are already othervise busy or overloaded...
(this is no rant against them, as all here are using their
personal free time to help out)
The biggest problem for me is that it is really difficult to test any
changes, one'd need a mockup of the whole buildsystem... and I don't
want to propose any patches blind :)
And to be honest I dont see that changing anytime soon...
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1/package/{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
Hm, how does this help with enabling backports (i.e. compared to simply
using cauldron repo)?
Anyway, would the above branch work like this:
e.g. lets imagine I want to, in order:
1. provide foobar 1.1 to backports.
2. cauldron foobar upgraded to 1.2, some patches added, some removed,
and other changes
3. provide foobar 1.2 to backports
4. 1.3 to cauldron and backports
To backport foobar 1.1, I guess I'd simply do
svn copy svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
and then the submit command.
When time comes to provide foobar 1.2 to backports, the options are:
Option 1:
svn del svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
svn copy svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
and submit. Changelog is the same as in cauldron.
Option 2:
svn checkout \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar/current \
foobar
cd foobar svn merge -r prevrev:HEAD \
svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar/current
svn commit
# copy all the log entries from the cauldron interval to the log msg
and submit.
Note: results in broken changelogs unless one does manual
markreleases, but changelogs are already broken both in mga1 updates
and in cauldron (youri issue [1]). This is more notable here, though,
as backports happen generally more often multiple times than updates.
Repeat with 1.3.
Correct?
[1] https://bugs.mageia.org/show_bug.cgi?id=2633
--
Anssi Hannula
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Op dinsdag 06 december 2011 00:29:03 schreef Anssi Hannula: On 06.12.2011 00:56, Thomas Backlund wrote: Now, here comes the question about backports once again. [...] Using a separate branch is also a cleaner way of providing backports, and makes it easy to separate changes needed only for Cauldron (or backports). Hm, how does this help with enabling backports (i.e. compared to simply using cauldron repo)? not sure, but i thought the problem we're facing now was that submitting from cauldron to backports was a problem in security scripting, ie: not being able to specify 2 sources? than this would solve that problem?
