[Mageia-dev] Update of backport, policy proposal

Sun Jun 26 12:57:49 CEST 2011

Le dimanche 26 juin 2011 à 11:58 +0300, atilla ontas a écrit :
+> 2011/6/26 Wolfgang Bornath <molch.b at googlemail.com>:
+> > A short reality check from userside:
+> >
+> > If foo-1.0 is in Mageia 1 and foo-1.1 is released upstream
+> >  - foo-1.1 will likely be integrated in Cauldron very soon after
+> >  - users will request to have foo-1.1 in Mageia 1
+> >  - if Mageia will not provide it then there will soon be local
+> > repositories where local packagers will do a "backport" for their
+> > friends.
+> >
+> > This may not be what Mageia backport policy will allow but we can not
+> > avoid people doing and using this, no matter how many warning signs we
+> > will publish. This has to be taken into account here.
+> >
+> > When a policy is found it has to be communicated very well, especially
+> > if that policy means that the user can not have foo-1.1 in his stable
+> > Mageia 1.
+> >
+> > This is important because former Mandriva users were used to get
+> > almost all new versions backported, if not officially then in 3rd
+> > party repos like MIB or MUD.
+> >
+> > --
+> > wobo
+> >
+> Hi. I'm following this threat from the very beginning. While reading,
+> i feel i'm reading a Mandriva Cooker mailing list posts. As a
+> community distro, why Mageia developers still think like a Mandriva
+> employee? Why backports and why so many policies, like a commercial
+> enterprise distro? I mean, Mageia do not have paid developers to work
+> on packages all the time. Also Mageia do not have so many packagers
+> like Fedora or Ubuntu, So, why make so many things so hard?
+
+If you adequate "commercial distro == policy", then I think you missed
+some steps. Just look at the number of packaging policy on Debian and
+Fedora.
+
+For debian start at http://www.debian.org/doc/debian-policy/ ( and
+various sub policy : http://www.debian.org/doc/packaging-manuals/ , not
+to count others that you can find on subteam such as
+http://pkg-haskell.alioth.debian.org/haskell-policy/ ).
+
+For Fedora, just look at :
+http://fedoraproject.org/wiki/Category:Packaging_guidelines
+
+
+We have open processes and not free-for-all because :
+- we can be sure that everybody do the same thing and know what can be
+done or not, ie, work like a community. 
+
+- we can direct newcomers to the our standard, as telling "you will
+discover by yourself" would be quite unfriendly to them. This is
+therefor required for and by growth.
+
+- a goal of a distribution is to have a coherent set of packages ( other
+wise, we , and to have that, we need to have a coherent set of rules, so
+they can inter-operate.
+
+- we want to set proper expectations. Expectations of those that use the
+system, because they have the guarantee of stability, or of having newer
+rpms. Expectation of the packager, because he know what can be done and
+would fail. 
+
+> As wobo mentioned, people like latest and greatest software. I think,
+> except a few users will use unofficial 3rd party repos to get latest
+> software. While i was maintaining MVT (Mandriva Turkiye) repository,
+> our users asked for GNOME 2.32 while Mandriva have GNOME 2.30 on
+> official release.
+
+And others people mentioned that people want also stable software and do
+not want changes. But as I said, what people want is not as important
+than what we can do, and so the decision is in the end of those that do
+the work rather than what people want, because if no one does the work,
+nothing happen.
+
+> Personally i always hate the backports structure and policy. It
+> confuses minds. Why Mageia need a backports repo, i really do not
+> understand. Stability and bug free releases are of course a must. But
+> it needs developers dedicated to work, almost paid developers. If a
+> software do not related with core system, like vlc, it should included
+> updates repo. Let upstream fix bugs and security issues. 
+
+So what you suggest is do like arch ?
+And when upstream is unable to reproduce the issue ( because he doesn't
+run the same distribution than the users that report ), what should be
+done ?
+
+> If a packager
+> catchs a bug he should send a patch to upstream and wait for a new
+> release. Otherwise, it is not packaging it is coding, which many
+> potential packgers will avoid to contribute.
+
+Sending a patch is coding. In fact, the more complex part is not to send
+a email with the file attached, it is to write the patch. 
+
+And once you have the patch, it is trivial to apply it to the rpm. 
+
+So the alternative is either we try to fixng for the bug ( which several
+packagers are perfectly able to do ), or we wait until it is fixed
+( which is usually unsatisfying for the users as some of them will see
+this as "the packager refused to listen to me and fix the bug" ).
+
+> Look at Debian and Arch Linux who haven't any paid developers but
+> community distros. Stable Debian releases provide software from a
+> century ago for the sake of stability. 
+
+Do not exaggerate. Software in Debian were perfectly fine when they were
+out, ( usually 1 to 2 year ago ), and now, they are "from a century
+ago" ? 
+
+And as lebahron noted in another thread, several people want stable
+release. Look at the time people kept windows xp.
+
+> Arch provides latest software
+> including core system and occaionally have breakages. I think Mageia
+> should be between two of them. Release latest software in updates for
+> non core system and libs, keep core system stable. Remove this
+> backports thingy.
+
+Sure, can you first start to define what is "non core" ( especially in
+the light of all SRPMS we currently have ) ? Bear in mind the various
+requires between all the required components.
+
+Usually, I recommend to people to look at various *BSD, as they provides
+exactly that, a core system with pkgsrc. The core is well defined, and
+everything below is updated with compiled ports. 
+
+But this requires to use a totally different workflow regarding kernel,
+glibc, coreutils etc, so people would have to convince kernel developers
+and glibc one first before anything. And I think the distribution that
+try to mimic this ( mimic because, unlike a bsd project, they do not
+take care of the libc and kernel part ) would be either Slackware or
+Arch. 
+
+-- 
+Michael Scherer
+
+