[Mageia-dev] Update of backport, policy proposal

Michael Scherer misc at zarb.org
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



More information about the Mageia-dev mailing list