FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 10-29-2010, 11:01 PM
Jeroen van Meeuwen
 
Default #15 relaxing guidelines wrt. bundling

Toshio Kuratomi wrote:

> If you're on packaging@lists.fp.o, we should probably take discussion

> there.

>

> Here's the fpc ticket with the question of whether we should relax the

> guidelines:

> https://fedorahosted.org/fpc/ticket/15

>

> Note that your description of the rubygem-passenger system could still fail

> to pass the test under revised guidelines depending on what they turn out

> to be. For instance, the guidelines might allow bundling of the latest

> upstream version or of the version provided by Fedora, or they might

> require that the package maintainer be able to code fixes should they be

> necessary. It's probably a good idea to join packaging@lists.fp.o and

> give reasons that requirements like that aren't needed.

>



As per the thread on advisory-board; http://lists.fedoraproject.org/pipermail/advisory-board/2010-October/009577.html



I urge you to consider to allow exceptions like these for the greater benefit of your users -and thus upstream, through Fedora.



Kind regards,



Jeroen van Meeuwen

-kanarip
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 10-31-2010, 02:41 PM
Toshio Kuratomi
 
Default #15 relaxing guidelines wrt. bundling

On Sat, Oct 30, 2010 at 12:01:25AM +0100, Jeroen van Meeuwen wrote:
> Toshio Kuratomi wrote:
>
> > If you're on packaging@lists.fp.o, we should probably take discussion
>
> > there.
>
> >
>
> > Here's the fpc ticket with the question of whether we should relax the
>
> > guidelines:
>
> > https://fedorahosted.org/fpc/ticket/15
>
> >
>
> > Note that your description of the rubygem-passenger system could still fail
>
> > to pass the test under revised guidelines depending on what they turn out
>
> > to be. For instance, the guidelines might allow bundling of the latest
>
> > upstream version or of the version provided by Fedora, or they might
>
> > require that the package maintainer be able to code fixes should they be
>
> > necessary. It's probably a good idea to join packaging@lists.fp.o and
>
> > give reasons that requirements like that aren't needed.
>
> >
>
> As per the thread on advisory-board; http://lists.fedoraproject.org/pipermail/
> advisory-board/2010-October/009577.html
>
> I urge you to consider to allow exceptions like these for the greater benefit
> of your users -and thus upstream, through Fedora.
>
The questions are how? and why?

Possible how: Allow apps to bundle libraries period.
Possible why: Because users are going to run the apps anyway and if they
come from Fedora, at least we can be providing updates to the broken
versions as the fixes become available instead of relying on the user to
seek them out.

Possible how: Apps are allowed to bundle libraries as long as the maintainer
commits to keeping the app ported to the newest version of the bundled
library within Fedora at all times.
Possible why: Security fixes and bugfixes to the library are going to be
pushed to the latest versions of packages in Fedora. We need to make sure
that the libraries are kept in sync so that we can consume those fixes
quickly if a problem arises. We need to make sure that there is someone
able to make fixes (the maintainer) in case a problem arises.

Possible how: Apps that bundle libraries must get a commitment from FES that
FES will maintain code in the apps should it be needed. The commitment must
be made for every release that Fedora is released for.
Possible why: FES is available to do coding work on the distribution.
If they sign up for maintaining a package's code, the maintainer does not
need to know how to program (only package). FES, being a group, allows
greater flexibility for fixing issues quickly should a security issue need
a quick turn-around.

Please add more suggestions -- I'm not really satisfied with any of these
so there's definitely room for improvement here.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 10-31-2010, 02:47 PM
Bruno Wolff III
 
Default #15 relaxing guidelines wrt. bundling

On Sun, Oct 31, 2010 at 08:41:14 -0700,
Toshio Kuratomi <a.badger@gmail.com> wrote:
>
> Possible how: Apps are allowed to bundle libraries as long as the maintainer
> commits to keeping the app ported to the newest version of the bundled
> library within Fedora at all times.

Is there going to be a tracking system for bundled libraries? This would
be useful when there are security fixes for a library so that someone could
find all of the packages that bundle that library. It could also be useful
for tracking aspects of bundling to help with decisions down the road.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 10-31-2010, 03:50 PM
Stephen John Smoogen
 
Default #15 relaxing guidelines wrt. bundling

2010/10/31 Toshio Kuratomi <a.badger@gmail.com>:
> On Sat, Oct 30, 2010 at 12:01:25AM +0100, Jeroen van Meeuwen wrote:
>> Toshio Kuratomi wrote:
>>

> Possible how: *Allow apps to bundle libraries period.
> Possible why: Because users are going to run the apps anyway and if they
> come from Fedora, at least we can be providing updates to the broken
> versions as the fixes become available instead of relying on the user to
> seek them out.
>
> Possible how: Apps are allowed to bundle libraries as long as the maintainer
> commits to keeping the app ported to the newest version of the bundled
> library within Fedora at all times.
> Possible why: Security fixes and bugfixes to the library are going to be
> pushed to the latest versions of packages in Fedora. *We need to make sure
> that the libraries are kept in sync so that we can consume those fixes
> quickly if a problem arises. *We need to make sure that there is someone
> able to make fixes (the maintainer) in case a problem arises.
>
> Possible how: Apps that bundle libraries must get a commitment from FES that
> FES will maintain code in the apps should it be needed. *The commitment must
> be made for every release that Fedora is released for.
> Possible why: FES is available to do coding work on the distribution.
> If they sign up for maintaining a package's code, the maintainer does not
> need to know how to program (only package). *FES, being a group, allows
> greater flexibility for fixing issues quickly should a security issue need
> a quick turn-around.
>
> Please add more suggestions -- I'm not really satisfied with any of these
> so there's definitely room for improvement here.
>

The creation of the "crap" repository. This area runs under less
restrictive packaging guidelines in order to allow for future
inclusion with the mainline. Things that would NOT be allowed in it:

1) Software that violates our Freedom clause (eg nonfree is a no-no).
2) Software that violates legal restrictions (patents, trademarks, and
similar software).

Software in this repository would be allowed to bundle libraries, but
would follow packaging guidelines. Due to the fact the software may
need regular updates to remain stable it would be allowed updates
during a release. It would not be QA'd beyond changes to the spec file
would need to be reviewed (like old fedora.us ways). It would not
override software in Fedora (thus it is either in the release or its
in "Crap" but not both).

Other repository names could be "feces", "fewmets", cow pies, cowplop,
road apples, fertilizer, guano, manure, meadow muffin, night soil,
ordure, poop

--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-01-2010, 09:33 AM
Stephen Gallagher
 
Default #15 relaxing guidelines wrt. bundling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/31/2010 12:50 PM, Stephen John Smoogen wrote:
> 2010/10/31 Toshio Kuratomi <a.badger@gmail.com>:
>> On Sat, Oct 30, 2010 at 12:01:25AM +0100, Jeroen van Meeuwen wrote:
>>> Toshio Kuratomi wrote:
>>>
>
>> Possible how: Allow apps to bundle libraries period.
>> Possible why: Because users are going to run the apps anyway and if they
>> come from Fedora, at least we can be providing updates to the broken
>> versions as the fixes become available instead of relying on the user to
>> seek them out.
>>
>> Possible how: Apps are allowed to bundle libraries as long as the maintainer
>> commits to keeping the app ported to the newest version of the bundled
>> library within Fedora at all times.
>> Possible why: Security fixes and bugfixes to the library are going to be
>> pushed to the latest versions of packages in Fedora. We need to make sure
>> that the libraries are kept in sync so that we can consume those fixes
>> quickly if a problem arises. We need to make sure that there is someone
>> able to make fixes (the maintainer) in case a problem arises.
>>
>> Possible how: Apps that bundle libraries must get a commitment from FES that
>> FES will maintain code in the apps should it be needed. The commitment must
>> be made for every release that Fedora is released for.
>> Possible why: FES is available to do coding work on the distribution.
>> If they sign up for maintaining a package's code, the maintainer does not
>> need to know how to program (only package). FES, being a group, allows
>> greater flexibility for fixing issues quickly should a security issue need
>> a quick turn-around.
>>
>> Please add more suggestions -- I'm not really satisfied with any of these
>> so there's definitely room for improvement here.
>>
>
> The creation of the "crap" repository. This area runs under less
> restrictive packaging guidelines in order to allow for future
> inclusion with the mainline. Things that would NOT be allowed in it:
>
> 1) Software that violates our Freedom clause (eg nonfree is a no-no).
> 2) Software that violates legal restrictions (patents, trademarks, and
> similar software).
>
> Software in this repository would be allowed to bundle libraries, but
> would follow packaging guidelines. Due to the fact the software may
> need regular updates to remain stable it would be allowed updates
> during a release. It would not be QA'd beyond changes to the spec file
> would need to be reviewed (like old fedora.us ways). It would not
> override software in Fedora (thus it is either in the release or its
> in "Crap" but not both).
>
> Other repository names could be "feces", "fewmets", cow pies, cowplop,
> road apples, fertilizer, guano, manure, meadow muffin, night soil,
> ordure, poop
>


See my post from October 29th to this list about using the FedoraPeople
repositories for this purpose, with the added benefit of NOT having
these packages signed (and therefore, official) parts of the Fedora project.

- --
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzOl34ACgkQeiVVYja6o6NCbQCeIF3YBtWzN5 qqTeNEPtG99JAe
VlgAoIe7KqgaKU5Si6eznp/19m/OMoux
=WEJX
-----END PGP SIGNATURE-----
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-01-2010, 12:20 PM
Jeroen van Meeuwen
 
Default #15 relaxing guidelines wrt. bundling

On Sunday, October 31, 2010 04:41:14 pm Toshio Kuratomi wrote:
> On Sat, Oct 30, 2010 at 12:01:25AM +0100, Jeroen van Meeuwen wrote:
> > As per the thread on advisory-board;
> > http://lists.fedoraproject.org/pipermail/
> > advisory-board/2010-October/009577.html
> >
> > I urge you to consider to allow exceptions like these for the greater
> > benefit of your users -and thus upstream, through Fedora.
>
> The questions are how? and why?
>
> Possible how: Allow apps to bundle libraries period.
> Possible why: Because users are going to run the apps anyway and if they
> come from Fedora, at least we can be providing updates to the broken
> versions as the fixes become available instead of relying on the user to
> seek them out.
>
> Possible how: Apps are allowed to bundle libraries as long as the
> maintainer commits to keeping the app ported to the newest version of the
> bundled library within Fedora at all times.
> Possible why: Security fixes and bugfixes to the library are going to be
> pushed to the latest versions of packages in Fedora. We need to make sure
> that the libraries are kept in sync so that we can consume those fixes
> quickly if a problem arises. We need to make sure that there is someone
> able to make fixes (the maintainer) in case a problem arises.
>

This means rebasing the bundled library and applying upstream's changes to
such bundled -but latest- version, right?

This would be perfectly reasonable, including the former option, possibly
including as much FES effort as possible. However, I suppose with the latter
option, in the case of Passenger, I'm not sure whether they would see it as a
breach of the trademark license. I suppose we could look at whether something
similar has ever occurred with Mozilla?

Kind regards,

Jeroen van Meeuwen
-kanarip
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-01-2010, 12:22 PM
Jeroen van Meeuwen
 
Default #15 relaxing guidelines wrt. bundling

On Sunday, October 31, 2010 05:50:16 pm Stephen John Smoogen wrote:
> 2010/10/31 Toshio Kuratomi <a.badger@gmail.com>:
> > On Sat, Oct 30, 2010 at 12:01:25AM +0100, Jeroen van Meeuwen wrote:
> >> Toshio Kuratomi wrote:
> > Possible how: Allow apps to bundle libraries period.
> > Possible why: Because users are going to run the apps anyway and if they
> > come from Fedora, at least we can be providing updates to the broken
> > versions as the fixes become available instead of relying on the user to
> > seek them out.
> >
> > Possible how: Apps are allowed to bundle libraries as long as the
> > maintainer commits to keeping the app ported to the newest version of
> > the bundled library within Fedora at all times.
> > Possible why: Security fixes and bugfixes to the library are going to be
> > pushed to the latest versions of packages in Fedora. We need to make
> > sure that the libraries are kept in sync so that we can consume those
> > fixes quickly if a problem arises. We need to make sure that there is
> > someone able to make fixes (the maintainer) in case a problem arises.
> >
> > Possible how: Apps that bundle libraries must get a commitment from FES
> > that FES will maintain code in the apps should it be needed. The
> > commitment must be made for every release that Fedora is released for.
> > Possible why: FES is available to do coding work on the distribution.
> > If they sign up for maintaining a package's code, the maintainer does not
> > need to know how to program (only package). FES, being a group, allows
> > greater flexibility for fixing issues quickly should a security issue
> > need a quick turn-around.
> >
> > Please add more suggestions -- I'm not really satisfied with any of these
> > so there's definitely room for improvement here.
>
> The creation of the "crap" repository. This area runs under less
> restrictive packaging guidelines in order to allow for future
> inclusion with the mainline.

"Packages that have not yet been reviewed and accepted. You are on your own.
Go eat babies!" - genious idea. It would prevent my pending review requests
from piling up year after year while withholding the package from the
consumers that may have an interest in the first place, as well.

Kind regards,

Jeroen van Meeuwen
-kanarip
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-01-2010, 12:23 PM
"Tom "spot" Callaway"
 
Default #15 relaxing guidelines wrt. bundling

On 11/01/2010 06:33 AM, Stephen Gallagher wrote:

> See my post from October 29th to this list about using the FedoraPeople
> repositories for this purpose, with the added benefit of NOT having
> these packages signed (and therefore, official) parts of the Fedora project.

FWIW, I support this, as my Chromium packages are in the Fedora People
repos, and technically, in violation of the current policy.

~spot
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-01-2010, 12:27 PM
Stephen Gallagher
 
Default #15 relaxing guidelines wrt. bundling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/01/2010 09:23 AM, Tom "spot" Callaway wrote:
> On 11/01/2010 06:33 AM, Stephen Gallagher wrote:
>
>> See my post from October 29th to this list about using the FedoraPeople
>> repositories for this purpose, with the added benefit of NOT having
>> these packages signed (and therefore, official) parts of the Fedora project.
>
> FWIW, I support this, as my Chromium packages are in the Fedora People
> repos, and technically, in violation of the current policy.


Actually, I had a discussion with the Fedora Hosted admins about this on
Friday. We determined that Chromium is NOT in violation of the current
policy on repos. Basically, the only two rules are: must be a compatible
license and must not be on the ForbiddenItems list.

My proposal is more of a marketing formalization of this policy: that
repos can be kept unofficial, but still on a fedora*.org domain so that
we retain the mindshare (as opposed to having joesrepo.geocities.com,
for example).



- --
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzOwEwACgkQeiVVYja6o6MbdQCgmofPYTdGVZ 66ZlVoYIQ73J+L
dpIAni7MOZZF+u73kHzAqMU7W6BVfTGV
=X+UW
-----END PGP SIGNATURE-----
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-01-2010, 01:45 PM
Toshio Kuratomi
 
Default #15 relaxing guidelines wrt. bundling

On Mon, Nov 01, 2010 at 02:20:11PM +0100, Jeroen van Meeuwen wrote:
> On Sunday, October 31, 2010 04:41:14 pm Toshio Kuratomi wrote:
> > On Sat, Oct 30, 2010 at 12:01:25AM +0100, Jeroen van Meeuwen wrote:
> > > As per the thread on advisory-board;
> > > http://lists.fedoraproject.org/pipermail/
> > > advisory-board/2010-October/009577.html
> > >
> > > I urge you to consider to allow exceptions like these for the greater
> > > benefit of your users -and thus upstream, through Fedora.
> >
> > The questions are how? and why?
> >
> > Possible how: Allow apps to bundle libraries period.
> > Possible why: Because users are going to run the apps anyway and if they
> > come from Fedora, at least we can be providing updates to the broken
> > versions as the fixes become available instead of relying on the user to
> > seek them out.
> >
> > Possible how: Apps are allowed to bundle libraries as long as the
> > maintainer commits to keeping the app ported to the newest version of the
> > bundled library within Fedora at all times.
> > Possible why: Security fixes and bugfixes to the library are going to be
> > pushed to the latest versions of packages in Fedora. We need to make sure
> > that the libraries are kept in sync so that we can consume those fixes
> > quickly if a problem arises. We need to make sure that there is someone
> > able to make fixes (the maintainer) in case a problem arises.
> >
>
> This means rebasing the bundled library and applying upstream's changes to
> such bundled -but latest- version, right?
>
Correct.

> This would be perfectly reasonable, including the former option, possibly
> including as much FES effort as possible. However, I suppose with the latter
> option, in the case of Passenger, I'm not sure whether they would see it as a
> breach of the trademark license. I suppose we could look at whether something
> similar has ever occurred with Mozilla?
>
I don't believe it has but that's just from the thoughts, opinions, etc,
that I'm seeing in the current round of Mozilla bundling tickets upstream.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 05:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org