6:01 p.m.
Toshio Kuratomi wrote:
If you're on packaging(a)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(a)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
10:41 a.m.
On Sat, Oct 30, 2010 at 12:01:25AM +0100, Jeroen van Meeuwen wrote:
Toshio Kuratomi wrote:
> If you're on packaging(a)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(a)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
10:47 a.m.
On Sun, Oct 31, 2010 at 08:41:14 -0700,
Toshio Kuratomi <a.badger(a)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.
10:05 a.m.
On Sun, Oct 31, 2010 at 10:47:52AM -0500, Bruno Wolff III wrote:
On Sun, Oct 31, 2010 at 08:41:14 -0700,
Toshio Kuratomi <a.badger(a)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.
Part of my rationale in the ticket for relaxing this rule is that we
changed the Guidelines during the last update to require that apps bundling
libraries must have a virtual Provide: that lists the library:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement...
An example might be rsync and zsync. They would have:
Provides: bundled(zlib) = 1.1.14
Note that no one has gone through the exception list yet and either opened
bugs on bundled libraries or had a provenpackager add the virtual provides.
If we pass relaxed guidelines, this would definitely need to be done.
-Toshio
11:50 a.m.
2010/10/31 Toshio Kuratomi <a.badger(a)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
5:33 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/31/2010 12:50 PM, Stephen John Smoogen wrote:
2010/10/31 Toshio Kuratomi <a.badger(a)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/
iEYEARECAAYFAkzOl34ACgkQeiVVYja6o6NCbQCeIF3YBtWzN5qqTeNEPtG99JAe
VlgAoIe7KqgaKU5Si6eznp/19m/OMoux
=WEJX
-----END PGP SIGNATURE-----
8:23 a.m.
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
8:27 a.m.
-----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/
iEYEARECAAYFAkzOwEwACgkQeiVVYja6o6MbdQCgmofPYTdGVZ66ZlVoYIQ73J+L
dpIAni7MOZZF+u73kHzAqMU7W6BVfTGV
=X+UW
-----END PGP SIGNATURE-----
8:22 a.m.
On Sunday, October 31, 2010 05:50:16 pm Stephen John Smoogen wrote:
2010/10/31 Toshio Kuratomi <a.badger(a)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
8:20 a.m.
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
9:45 a.m.
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
10:09 a.m.
On 11/01/2010 10:45 AM, Toshio Kuratomi wrote:
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.
From my previous dealings with Mozilla, they would see this as an
"unapproved" change, and consider any distribution of such a work as a
violation of their Trademark Usage Guidelines.
~spot
4918
days inactive
4921
days old
packaging@lists.fedoraproject.org
11 comments
6 participants
participants (6)
-
Bruno Wolff III -
Jeroen van Meeuwen -
Stephen Gallagher -
Stephen John Smoogen -
Tom Callaway -
Toshio Kuratomi