Re: [Mageia-dev] Various proposals around backports and other media management
Le lundi 18 octobre 2010 à 15:09 +0300, Anssi Hannula a écrit : > On Wednesday 06 October 2010 09:44:37 Samuel Verschelde wrote: > > Le mercredi 6 octobre 2010 00:06:41, Buchan Milne a écrit : > > > As long as it doesn't take the focus off the development release. In > > > Mandriva, I think there were some uploads to backports before the > > > upload to cooker, which can cause problems for users if not corrected. > > > > Indeed. I think that the current policy already tries to enforce that. Those > > uploads to backports before upload to cooker were mistakes. > > What about when cooker is in freeze? If we are in freeze, I would try to focus our ressources on bug fixing. Having to wait for a backport never caused much troubles. Not fixing a bug in a new version we try to mark as stable is much more problematic, IMHO. Alternatively, a system like Fedora and Debian have would maybe lessen the issue. Ie, once you decide to freeze, you fork the distribution, but you don't label it as stable. Then cooker/cauldron is updated as usual, and only bugfixes are pushed to the forked distribution, before it got labeled as stable. And we can imagine to even have backport pushed to this distribution. See http://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal and the various debian wiki pages for testing/unstable relation, and the policy after a freeze. -- Michael Scherer
Re: [Mageia-dev] Various proposals around backports and other media management
On Wednesday 06 October 2010 09:44:37 Samuel Verschelde wrote: > Le mercredi 6 octobre 2010 00:06:41, Buchan Milne a écrit : > > As long as it doesn't take the focus off the development release. In > > Mandriva, I think there were some uploads to backports before the > > upload to cooker, which can cause problems for users if not corrected. > > Indeed. I think that the current policy already tries to enforce that. Those > uploads to backports before upload to cooker were mistakes. What about when cooker is in freeze? I guess we should allow backports to cooker backports then? -- Anssi Hannula
Re: [Mageia-dev] Various proposals around backports and other media management
Le mercredi 6 octobre 2010 12:20:54, Michael Scherer a écrit : > > Le mardi 05 octobre 2010 à 23:06 +0100, Buchan Milne a écrit : > > On Tuesday, 5 October 2010 19:46:45 Samuel Verschelde wrote: > > > > Some user communities already did that for 3rd party > > > repositories for Mandriva, and having it in a centralized and visible > > > place would make backports more visible. How many users know that latest > > > versions for wine, wesnoth (one of the best opensource games), vlc, and > > > many other packages are already available in backports media for mandriva > > > ? Today there is a changelog mailing list, but this is not for everyone. > > > This would be more user-centric than packager-centric. I tried to improve > > > backports visibility on the Mandriva forum, but without any automation it > > > took an enormous amount of time to maintain : > > > http://forum.mandriva.com/viewforum.php?f=123 (see threads beginning with > > > "New Soft" or "Backport") > > > > RSS feed or use of twitter by build system may be useful > > Youri already have RSS, afaik. > http://www.zarb.org/cgi-bin/viewvc.cgi/youri/soft/submit/trunk/lib/Youri/Submit/Step/Action/RSS.pm?revision=2100&view=markup > > Twitter/statusnet could be easy to add , according to > http://status.net/wiki/Libraries , this would quite trivial > > I even think that a plugin to post on a forum could be done. A little > bit less trivial, but I am ok to work on it, once everything we have is > running. There's some part that is manual, that's why I thought some part could be automated, then part of the documentation team (which I would join for this task) would have to : - explain what changed (and/or copy the changelog from the projects site for version updates) - add screenshots of the software (it just looks good with screenshots, and you see That's why I thought that a dedicated place on the website (must join the webmaster team for that... How many teams will I join ? :p) would be better than the forum, but this is debatable. Another reason is that the website may be translated (update annouces in your own langage is a real plus), whereas I don't think it'll be easy with the forum. However, before having the full-featured thing, why not start by automated posts to the forum ! Regards Samuel
Re: [Mageia-dev] Various proposals around backports and other media management
Michael Scherer skrev 6.10.2010 13:20: Le mardi 05 octobre 2010 à 23:06 +0100, Buchan Milne a écrit : As long as it doesn't take the focus off the development release. In Mandriva, I think there were some uploads to backports before the upload to cooker, which can cause problems for users if not corrected. We have solved the problem at PLF by forcing build to appear in cooker first. It is just a youri plugin. Yeah, we need to enforce Cauldron first (for one week ?), then backports -- thomas
Re: [Mageia-dev] Various proposals around backports and other media management
Michael Scherer skrev 6.10.2010 13:20: > Le mardi 05 octobre 2010 à 23:06 +0100, Buchan Milne a écrit : >> As long as it doesn't take the focus off the development release. In Mandriva, >> I think there were some uploads to backports before the upload to cooker, >> which can cause problems for users if not corrected. > > We have solved the problem at PLF by forcing build to appear in cooker > first. It is just a youri plugin. > Yeah, we need to enforce Cauldron first (for one week ?), then backports -- thomas
Re: [Mageia-dev] Various proposals around backports and other media management
Le mardi 05 octobre 2010 à 23:06 +0100, Buchan Milne a écrit : > On Tuesday, 5 October 2010 19:46:45 Samuel Verschelde wrote: > > Some user communities already did that for 3rd party > > repositories for Mandriva, and having it in a centralized and visible > > place would make backports more visible. How many users know that latest > > versions for wine, wesnoth (one of the best opensource games), vlc, and > > many other packages are already available in backports media for mandriva > > ? Today there is a changelog mailing list, but this is not for everyone. > > This would be more user-centric than packager-centric. I tried to improve > > backports visibility on the Mandriva forum, but without any automation it > > took an enormous amount of time to maintain : > > http://forum.mandriva.com/viewforum.php?f=123 (see threads beginning with > > "New Soft" or "Backport") > > RSS feed or use of twitter by build system may be useful Youri already have RSS, afaik. http://www.zarb.org/cgi-bin/viewvc.cgi/youri/soft/submit/trunk/lib/Youri/Submit/Step/Action/RSS.pm?revision=2100&view=markup Twitter/statusnet could be easy to add , according to http://status.net/wiki/Libraries , this would quite trivial I even think that a plugin to post on a forum could be done. A little bit less trivial, but I am ok to work on it, once everything we have is running. > > - (the biggest part, but the one with most long term benefits I hope) add > > metadata to media to make urpmi more media-aware. Today, rpmdrake detects > > backports because the backports media have "backports" in their name. > > That's a (useful) hack, but we could do better. One solution could be to > > give metadata to each media : * release vs updates vs backports > > * testing vs stable > > * debug vs non-debug > > Combination of these "tags" would give the following media : > > * main release (just like today's media) > > * main updates > > * main updates testing : for update candidates, this is our current > > "main testing" media * main backports > > * main backports testing : for backports candidates (as someone who > > frequently does backports, I sometimes feel the lack for it) > > As long as it doesn't take the focus off the development release. In > Mandriva, > I think there were some uploads to backports before the upload to cooker, > which can cause problems for users if not corrected. We have solved the problem at PLF by forcing build to appear in cooker first. It is just a youri plugin. -- Michael Scherer
Re: [Mageia-dev] Various proposals around backports and other media management
Le mercredi 6 octobre 2010 00:06:41, Buchan Milne a écrit : > > On Tuesday, 5 October 2010 19:46:45 Samuel Verschelde wrote: > > - a section on the mageia website dedicated to package updates : what's new > > in security/bugfix updates, what's new in backports (aka version updates), > > ... with screen captures, description of what changed in this version, > > links to upstream websites, comments from users, focus on some > > applications... > > Please take into consideration features that might be beneficial to package > maintainers as well. If you haven't yet, please look at e.g. Youri project, > Sophie etc. The one I'm talking about would be primarily geared towards end-users. However, why not indeed share efforts between packager's needs and user's needs. Some are common, others aren't. With a clever architecture, this is attainable. What about a unique back-end, but 2 different frontends ? > > RSS feed or use of twitter by build system may be useful Indeed. I thought about them but forgot to write them down. > > - (the biggest part, but the one with most long term benefits I hope) add > > metadata to media to make urpmi more media-aware. Today, rpmdrake detects > > backports because the backports media have "backports" in their name. > > That's a (useful) hack, but we could do better. One solution could be to > > give metadata to each media : * release vs updates vs backports > > * testing vs stable > > * debug vs non-debug > > Combination of these "tags" would give the following media : > > * main release (just like today's media) > > * main updates > > * main updates testing : for update candidates, this is our current > > "main testing" media * main backports > > * main backports testing : for backports candidates (as someone who > > frequently does backports, I sometimes feel the lack for it) > > As long as it doesn't take the focus off the development release. In > Mandriva, > I think there were some uploads to backports before the upload to cooker, > which can cause problems for users if not corrected. Indeed. I think that the current policy already tries to enforce that. Those uploads to backports before upload to cooker were mistakes. I don't think that this media structure would change many things in the way that we packagers work, however. Benefits should be mainly for users. Samuel
[Mageia-dev] Various proposals around backports and other media management
Hello to everyone on the list,
As some people said in another thread, Mandriva's current media schema already
gives the opportunity to :
- install newer versions of software if needed (from backports media),
- keep a stable system with only security fixes if needed (updates media, for
servers or any workstation where stability counts more than being bleeding-edge)
However, we can improve things around backports, updates, testing and debug
media for the end user's benefit.
I'd like to propose the following improvements if you think they would be good
(and I'm ready to help make them happen) :
- a section on the mageia website dedicated to package updates : what's new in
security/bugfix updates, what's new in backports (aka version updates), ...
with screen captures, description of what changed in this version, links to
upstream websites, comments from users, focus on some applications... Some user
communities already did that for 3rd party repositories for Mandriva, and
having it in a centralized and visible place would make backports more visible.
How many users know that latest versions for wine, wesnoth (one of the best
opensource games), vlc, and many other packages are already available in
backports media for mandriva ? Today there is a changelog mailing list, but
this is not for everyone.
This would be more user-centric than packager-centric. I tried to improve
backports visibility on the Mandriva forum, but without any automation it took
an enormous amount of time to maintain :
http://forum.mandriva.com/viewforum.php?f=123 (see threads beginning with "New
Soft" or "Backport")
- add a "welcome" screen to rpmdrake, where people could choose between :
* Browse and install security / bugfix updates
* Browse and install new versions of software ("backports")
* Install new software
* Uninstall software
* Skip this newbie step and get me to the real stuff, I'll use the various
options to do what I need
Rpmdrake can also be enhanced to show for each package update whether it's a
backport or a standard update. It's not easy currently (you have to dig into
package details).
- (the biggest part, but the one with most long term benefits I hope) add
metadata to media to make urpmi more media-aware. Today, rpmdrake detects
backports because the backports media have "backports" in their name. That's a
(useful) hack, but we could do better. One solution could be to give metadata
to each media :
* release vs updates vs backports
* testing vs stable
* debug vs non-debug
Combination of these "tags" would give the following media :
* main release (just like today's media)
* main updates
* main updates testing : for update candidates, this is our current "main
testing" media
* main backports
* main backports testing : for backports candidates (as someone who
frequently does backports, I sometimes feel the lack for it)
* main release debug...
* contrib...
* non-free...
It may seem a lot of media, but in fact you have to think they all are only
flavours of the main, contrib, non-free, and other media. We can think of a
better presentation in UI tools that will in fact make them appear less
cluttered than it is today :
http://stormi.lautre.net/fichiers/mageia/media-configuration-proposal.ods
In CLI, urpmi would default to using only release and updates media (which you
could change in configuration if needed), and you could use other media with
the following switches for example :
--use-backports : enables all backports media
--use-testing : enables all testing media
--use-debug : enables all debug media
This way, no one would have to activate/unactivate the various media globally
anymore. Let's say you need to test the latest vlc backport before it goes to
"stable" backports. You'll type : urpmi vlc vlc-debug --use-backports
--use-testing --use-debug and voilà ! No need to temporarily activate
backports, testing and debug media globally, or specify every media manually
via the --media switch.
To not put too much burden on mirrors, packages going from a testing media to
an non-testing media would be removed from the testing media.
This proposals are open to discussion, of course, as I have no power of
decision and may be wrong. I guess there may be several weak points in my view,
but I'm sure there are also strong points.
Regards
Samuel Verschelde
