OK guys, here's the item that I've been working on with the JPackage folks for a while:
http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
This exception documents how Java packages which come from JPackage are to be handled, and paves the way for the eventual removal of the jpp tag.
Fernando Nasser, Jesse Keating, and many others helped me put this together, and they all seem pretty happy with what we've got in this final draft.
FPC members: Please vote on this item.
Thanks,
~spot
On Tuesday 30 January 2007 15:46, Tom 'spot' Callaway wrote:
http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
This exception documents how Java packages which come from JPackage are to be handled, and paves the way for the eventual removal of the jpp tag.
Fernando Nasser, Jesse Keating, and many others helped me put this together, and they all seem pretty happy with what we've got in this final draft.
FPC members: Please vote on this item.
+1
Thanks for the hard work on this!
Tom 'spot' Callaway wrote:
OK guys, here's the item that I've been working on with the JPackage folks for a while:
http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
This exception documents how Java packages which come from JPackage are to be handled, and paves the way for the eventual removal of the jpp tag.
Fernando Nasser, Jesse Keating, and many others helped me put this together, and they all seem pretty happy with what we've got in this final draft.
FPC members: Please vote on this item.
+1
-- Rex
On Tue, 2007-01-30 at 14:46 -0600, Tom 'spot' Callaway wrote:
OK guys, here's the item that I've been working on with the JPackage folks for a while:
http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
This exception documents how Java packages which come from JPackage are to be handled, and paves the way for the eventual removal of the jpp tag.
Fernando Nasser, Jesse Keating, and many others helped me put this together, and they all seem pretty happy with what we've got in this final draft.
FPC members: Please vote on this item.
+1.
Great work spot, fnasser, and f13!
-Toshio
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> This exception documents how Java packages which come from TC> JPackage are to be handled, and paves the way for the eventual TC> removal of the jpp tag.
I have no problem with granting the exception, but I do think the definition of the exception should include a explicitly state the conditions under which it will go away.
The linked document has rationale and ideas for things to be added to rpm and yum under the "Proposal" section, but there's no clear statement of just how long the exception is to be granted. (Perhaps it's intended to be permanent; it's just not clear from the document.)
- J<
On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote:
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> This exception documents how Java packages which come from TC> JPackage are to be handled, and paves the way for the eventual TC> removal of the jpp tag.
I have no problem with granting the exception, but I do think the definition of the exception should include a explicitly state the conditions under which it will go away.
The linked document has rationale and ideas for things to be added to rpm and yum under the "Proposal" section, but there's no clear statement of just how long the exception is to be granted. (Perhaps it's intended to be permanent; it's just not clear from the document.)
Unfortunately, the exception will be permanent for the Java packages from JPackage. The exception will be modified when we can safely drop the jpp tag from Fedora.
~spot
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> Unfortunately, the exception will be permanent for the Java TC> packages from JPackage. The exception will be modified when we can TC> safely drop the jpp tag from Fedora.
Perhaps you can understand my confusion, then. Here's my understanding:
There's a singluar issue: the portion of the release field before the dist tag is not an integer and neither of the two exceptions in the NamingGuidelines apply. The proposed exception, for Java packages from JPackage only, is:
*) Temporarily allow release to take the form Xjpp.Y%{?dist}[.Z] until the detailed changes to rpm and yum render the "jpp" unnecessary.
*) Permanently allow release to take the form X.Y%{?dist}[.Z]
Where X, Y, and Z are integers defined in the proposal.
If that's correct, then +1.
- J<
On Tue, 2007-01-30 at 18:57 -0600, Jason L Tibbitts III wrote:
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> Unfortunately, the exception will be permanent for the Java TC> packages from JPackage. The exception will be modified when we can TC> safely drop the jpp tag from Fedora.
Perhaps you can understand my confusion, then. Here's my understanding:
There's a singluar issue: the portion of the release field before the dist tag is not an integer and neither of the two exceptions in the NamingGuidelines apply. The proposed exception, for Java packages from JPackage only, is:
*) Temporarily allow release to take the form Xjpp.Y%{?dist}[.Z] until the detailed changes to rpm and yum render the "jpp" unnecessary.
*) Permanently allow release to take the form X.Y%{?dist}[.Z]
Where X, Y, and Z are integers defined in the proposal.
If that's correct, then +1.
Yes, that is correct.
~spot
On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote:
> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> This exception documents how Java packages which come from TC> JPackage are to be handled, and paves the way for the eventual TC> removal of the jpp tag.
I have no problem with granting the exception, but I do think the definition of the exception should include a explicitly state the conditions under which it will go away.
The linked document has rationale and ideas for things to be added to rpm and yum under the "Proposal" section, but there's no clear statement of just how long the exception is to be granted. (Perhaps it's intended to be permanent; it's just not clear from the document.)
Unfortunately, the exception will be permanent for the Java packages from JPackage. The exception will be modified when we can safely drop the jpp tag from Fedora.
Err.. If you mean "permanent for the Java packages *in* JPackage" then I'm still okay with the proposal. Otherwise I'm changing my vote....
-Toshio
On Tue, 2007-01-30 at 17:30 -0800, Toshio Kuratomi wrote:
On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote:
>> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> This exception documents how Java packages which come from TC> JPackage are to be handled, and paves the way for the eventual TC> removal of the jpp tag.
I have no problem with granting the exception, but I do think the definition of the exception should include a explicitly state the conditions under which it will go away.
The linked document has rationale and ideas for things to be added to rpm and yum under the "Proposal" section, but there's no clear statement of just how long the exception is to be granted. (Perhaps it's intended to be permanent; it's just not clear from the document.)
Unfortunately, the exception will be permanent for the Java packages from JPackage. The exception will be modified when we can safely drop the jpp tag from Fedora.
Err.. If you mean "permanent for the Java packages *in* JPackage" then I'm still okay with the proposal. Otherwise I'm changing my vote....
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
~spot
On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-01-30 at 17:30 -0800, Toshio Kuratomi wrote:
On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote:
>>> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> This exception documents how Java packages which come from TC> JPackage are to be handled, and paves the way for the eventual TC> removal of the jpp tag.
I have no problem with granting the exception, but I do think the definition of the exception should include a explicitly state the conditions under which it will go away.
The linked document has rationale and ideas for things to be added to rpm and yum under the "Proposal" section, but there's no clear statement of just how long the exception is to be granted. (Perhaps it's intended to be permanent; it's just not clear from the document.)
Unfortunately, the exception will be permanent for the Java packages from JPackage. The exception will be modified when we can safely drop the jpp tag from Fedora.
Err.. If you mean "permanent for the Java packages *in* JPackage" then I'm still okay with the proposal. Otherwise I'm changing my vote....
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
So Fedora will never have java packages of its own and depend on jpp?
If so, fedora seems to be missing it's objectives, as it seems to me?
Ralf
On Wed, 2007-01-31 at 18:27 +0100, Ralf Corsepius wrote:
On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-01-30 at 17:30 -0800, Toshio Kuratomi wrote:
On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote:
>>>> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> This exception documents how Java packages which come from TC> JPackage are to be handled, and paves the way for the eventual TC> removal of the jpp tag.
I have no problem with granting the exception, but I do think the definition of the exception should include a explicitly state the conditions under which it will go away.
The linked document has rationale and ideas for things to be added to rpm and yum under the "Proposal" section, but there's no clear statement of just how long the exception is to be granted. (Perhaps it's intended to be permanent; it's just not clear from the document.)
Unfortunately, the exception will be permanent for the Java packages from JPackage. The exception will be modified when we can safely drop the jpp tag from Fedora.
Err.. If you mean "permanent for the Java packages *in* JPackage" then I'm still okay with the proposal. Otherwise I'm changing my vote....
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
So Fedora will never have java packages of its own and depend on jpp?
If so, fedora seems to be missing it's objectives, as it seems to me?
No, it certainly can (and does) have java packages that don't come from JPackage. This exception is only for those packages which originate from jpp.
~spot
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
RC> So Fedora will never have java packages of its own and depend on RC> jpp?
I'm having trouble understanding how you get from spot's statement above to your conclusion.
There are some packages which come from jpackage and there are some that don't. Has it been stated otherwise somewhere?
- J<
On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote:
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
RC> So Fedora will never have java packages of its own and depend on RC> jpp?
I'm having trouble understanding how you get from spot's statement above to your conclusion.
There are some packages which come from jpackage and there are some that don't.
Then you might be able to explain why * compatibility to packages from a 3rd party repo such as jpackage are of any importance to Fedora.
Except that people ARE mixing jpp-packages with Fedora, just like they do with freshrpms, atrpms, livna, dribble and many others I don't see any difference.
* why the origin of a package is of any importance to Fedora?
Has it been stated otherwise somewhere?
Yes, e.g. his sentence above. I read this as "we will always continue to use jpp packages, and do not package java on our own".
Ralf
On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote:
On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote:
> "RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
RC> So Fedora will never have java packages of its own and depend on RC> jpp?
I'm having trouble understanding how you get from spot's statement above to your conclusion.
There are some packages which come from jpackage and there are some that don't.
Then you might be able to explain why
- compatibility to packages from a 3rd party repo such as jpackage are
of any importance to Fedora.
Except that people ARE mixing jpp-packages with Fedora, just like they do with freshrpms, atrpms, livna, dribble and many others I don't see any difference.
I don't think it's bad that Fedora cares about compatibility with 3rd party repos, in fact I wish that this kind of mutual cooperation rather extends.
As a general rule of thumb I would say that
o cooperation enlarges the community and that's one of Fedora's strength, o if it's cheaper for Fedora to cater for compatibility than reinvent the wheel, then why not? o if compatibility obstructs otherwise something and is not worth it can always be dumped, i.e. it is not the highest goal
On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote:
On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote:
On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote:
>> "RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
RC> So Fedora will never have java packages of its own and depend on RC> jpp?
I'm having trouble understanding how you get from spot's statement above to your conclusion.
There are some packages which come from jpackage and there are some that don't.
Then you might be able to explain why
- compatibility to packages from a 3rd party repo such as jpackage are
of any importance to Fedora.
Except that people ARE mixing jpp-packages with Fedora, just like they do with freshrpms, atrpms, livna, dribble and many others I don't see any difference.
I don't think it's bad that Fedora cares about compatibility with 3rd party repos,
Neither do I.
in fact I wish that this kind of mutual cooperation rather extends.
Exactly this is the point, I am asking: Why explicitly care about jpp?
Ralf
On Thu, Feb 01, 2007 at 08:39:38AM +0100, Ralf Corsepius wrote:
On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote:
On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote:
On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote:
>>> "RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
RC> So Fedora will never have java packages of its own and depend on RC> jpp?
I'm having trouble understanding how you get from spot's statement above to your conclusion.
There are some packages which come from jpackage and there are some that don't.
Then you might be able to explain why
- compatibility to packages from a 3rd party repo such as jpackage are
of any importance to Fedora.
Except that people ARE mixing jpp-packages with Fedora, just like they do with freshrpms, atrpms, livna, dribble and many others I don't see any difference.
I don't think it's bad that Fedora cares about compatibility with 3rd party repos,
Neither do I.
in fact I wish that this kind of mutual cooperation rather extends.
Exactly this is the point, I am asking: Why explicitly care about jpp?
OK, sorry I misunderstood you completely, I read your comments like criticism for cooperation.
I can only guess about why jpp is treated "better" than other repos:
o one needs to start somewhere o java is a key technology also required for RHEL, so there is vital interest in RH for it. o less patent encumbered/closed source parts than other repos o good quality packaging
If I didn't knew better I'd add
o good cooperation with the 3rd party maintainers
but according to some of Jesse's comments this seems to be less the case (or was, it may have improved since).
On Thu, 2007-02-01 at 08:48 +0100, Axel Thimm wrote:
On Thu, Feb 01, 2007 at 08:39:38AM +0100, Ralf Corsepius wrote:
On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote:
On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote:
On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote:
>>>> "RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
> The Java packages in Fedora which originally come from the JPackage > repo are the only packages which fall under this exception. And > those packages will always fall under this exception, forever and > ever, amen (or until something dramatic changes).
RC> So Fedora will never have java packages of its own and depend on RC> jpp?
I'm having trouble understanding how you get from spot's statement above to your conclusion.
There are some packages which come from jpackage and there are some that don't.
Then you might be able to explain why
- compatibility to packages from a 3rd party repo such as jpackage are
of any importance to Fedora.
Except that people ARE mixing jpp-packages with Fedora, just like they do with freshrpms, atrpms, livna, dribble and many others I don't see any difference.
I don't think it's bad that Fedora cares about compatibility with 3rd party repos,
Neither do I.
in fact I wish that this kind of mutual cooperation rather extends.
Exactly this is the point, I am asking: Why explicitly care about jpp?
OK, sorry I misunderstood you completely, I read your comments like criticism for cooperation.
Let me put it this way:
To me, it is a bit bewildering to see a project initially being launched as "integration platform for 3rd parties" to explicitly take one of its "rivals" into consideration as a "special exception" that someone labeled "forever, ... amen".
If "Fedora integration" really works out, then we should see "integrated packages" and external 3rd party providing add-on packages, which should be treated as private pleasures of those implementing it.
If Fedora wants to take external repos into account, then I'd prefer not to see a singular exception for jpp, but generally applicable rules. Unfortunately, I don't see how this can be implemented nor am I expecting much interest from inside Fedora to address this any time soon.
I can only guess about why jpp is treated "better" than other repos:
o one needs to start somewhere o java is a key technology also required for RHEL, so there is vital interest in RH for it.
Probably, only somebody @redcom.com can answer this, but I would not deny this thought.
o less patent encumbered/closed source parts than other repos
Patents yes.
Wrt. "non-free" I don't see that jpp is substantially different from how livna and other 3rd parties shipping "non-free"/non-OSI compliant package.
Wrt. voting, I am undecided, because, to me, the proposal boils down to deciding between two "mediocre compromises":
a) Accepting it would mean catering a pragmatical compromise, which isn't necessarily in the Fedora community's long-term interests and which might weaken OpenSource in longer terms.
b) Rejecting it would mean insisting on a position that isn't necessarily in RH's nor Fedora's interest wrt. java, technically is hardly resolvable, but would help the "wider community" (3rd parties).
I would have voted +1 if I'd sense this proposal to be a short-term compromise and precedence aiming at systematic integration of 3rd parties. Spot's comment lets me think this doesn't apply.
Ralf
On Thu, Feb 01, 2007 at 10:21:35AM +0100, Ralf Corsepius wrote:
technically is hardly resolvable,
I'm not sure it's really that hard unless I'm overseeing something. See my other post on how we can import jpp packages w/o sacrificing guideline sanity, e.g. by using <jpp-releaseint>{.|-}<our release tag> hierarchy (e.g. removing the jpp string) and not endorsing any post-disttag tagging than we already do.
Le Jeu 1 février 2007 10:21, Ralf Corsepius a écrit :
a) Accepting it would mean catering a pragmatical compromise, which isn't necessarily in the Fedora community's long-term interests and which might weaken OpenSource in longer terms.
Could the Don Quichottes that are objecting to peaceful jpp cooperation provide documented examples when working with jpp has been harmful to Fedora (aside from the "harm" of three letters in versions?)
Could we have more concrete arguments than it "isn't necessarily in the Fedora community's long-term interests" ?
Do you realise the only reason we have a packaged FLOSS java stack today (and not in two years) is it was bootstraped on closed jpp jvm packages ?
Is breaking ties with other entities for the sake of not having to think about them in the Fedora community's long-term interest ?
/me is getting mad about all the FUDing on this issue.
On Thu, 2007-02-01 at 10:52 +0100, Nicolas Mailhot wrote:
Le Jeu 1 février 2007 10:21, Ralf Corsepius a écrit :
a) Accepting it would mean catering a pragmatical compromise, which isn't necessarily in the Fedora community's long-term interests and which might weaken OpenSource in longer terms.
Could the Don Quichottes that are objecting to peaceful jpp cooperation provide documented examples when working with jpp has been harmful to Fedora (aside from the "harm" of three letters in versions?)
Could we have more concrete arguments than it "isn't necessarily in the Fedora community's long-term interests" ?
IMO, if Fedora was gradually approaching it's initial objectives, we would have FLOSS java packages inside of FE and would not have to resort to using jpp - That's why I was asking if Fedora was failing on java.
Do you realise the only reason we have a packaged FLOSS java stack today (and not in two years) is it was bootstraped on closed jpp jvm packages ?
I do - But do you realize that the only reason I am able to run Fedora in reasonable manners at all is using non-free packages from livna, jpp and other sources?
It's the reason why I am all for implementing ways to allow better integration of 3rd party repos. But pushing jpp into a special exception, to me means "measuring by double standards".
Is breaking ties with other entities for the sake of not having to think about them in the Fedora community's long-term interest?
What makes you think this? Firstly, I am not the FPC, I am just an individual with an opinion, who happens to have a vote within the FPC.
And I hope to have been clear enough, on not having made up my mind, yet but to be considering the trade-offs.
In a nutshell, the question is quite simple: Why should jpp put into a special position and other 3rd parties be ignored, which (at least for my way of using Fedora) are equally vitally important?
We would not have this discussion if Spot was "giving a deadline and was talking about a transitional limited period of time" or if this all was about "using jpp as precedence on 3rd party integration".
Or differently: * Empower me with arguments why Fedora's java needs the jpp suffix? * Empower me with arguments why jpp package can't be merge into Fedora?
Don't get me wrong, I am seriously asking and want to know.
Ralf
On Thursday 01 February 2007 07:30, Ralf Corsepius wrote:
In a nutshell, the question is quite simple: Why should jpp put into a special position and other 3rd parties be ignored, which (at least for my way of using Fedora) are equally vitally important?
We only allow importing of the free jpp packages. We have our own java compiler and runtime (gcj) that is used for our jpp packages rather than the non-free jvm. If the jvm was free, the answer for java on Fedora might actually be "use jpackage, here is a repo file" but that isn't the case.
On Thursday 01 February 2007 07:30, Ralf Corsepius wrote:
Or differently:
- Empower me with arguments why Fedora's java needs the jpp suffix?
These are in the wiki. Please point out what you don't understand.
- Empower me with arguments why jpp package can't be merge into Fedora?
jpp in this case is considered an upstream. The upstream isn't where the jar files and such live, jpp is, and jpp happens to release things in (s)rpm form. This makes it very easy to import the srpms, as jpackage is striving to follow _our_ guidelines so that this can happen. There are some folks what work in jpackage that have very strong desires to _not_ sign CLAs or not contribute directly to Fedora/Red Hat. I respect these desires, and continue to see jpackage is a vibrant package upstream for java users. Our java team chooses to do their packaging work within the jpackage upstream, benefiting all users of jpackage, not just Fedora. Not every distribution wants gcj compiled java, that's just something Fedora has to do for legal/oss reasons.
On Thu, 2007-02-01 at 10:21 +0100, Ralf Corsepius wrote:
Wrt. voting, I am undecided, because, to me, the proposal boils down to deciding between two "mediocre compromises":
a) Accepting it would mean catering a pragmatical compromise, which isn't necessarily in the Fedora community's long-term interests and which might weaken OpenSource in longer terms.
b) Rejecting it would mean insisting on a position that isn't necessarily in RH's nor Fedora's interest wrt. java, technically is hardly resolvable, but would help the "wider community" (3rd parties).
I would have voted +1 if I'd sense this proposal to be a short-term compromise and precedence aiming at systematic integration of 3rd parties. Spot's comment lets me think this doesn't apply.
I am treating this very much as a compromise with limited scope aiming at assisting in the integration and compatibility with 3rd party repositories. However, in order to limit the scope, it is currently only valid for JPackage. If another repo comes forward which would wish to leverage the same guideline set, I'm more than willing to amend it for them.
~spot
Le Jeu 1 février 2007 08:39, Ralf Corsepius a écrit :
On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote:
in fact I wish that this kind of mutual cooperation rather extends.
Exactly this is the point, I am asking: Why explicitly care about jpp?
Because as far as I know that's the only 3rd-party repository that managed: - to get community packagers from different distros working together - to get paid distro packagers work with the community packagers - to create a common rpm namespace accross rpm distros (unfortunately debian got its own affort on rails at about the same time so you still have a rpm/deb disconnect) - to have packaging work flow both to and from fedora (and other distros)
I don't know if the jpp model could be extended. It was successful largely because there was no in-distro java packaging when jpp was created, vendor java packaging was awful, so there was no competing packagesets and NIH attitudes to work against.
You'll note when jpp is involved @rh people argue for 3rd-party cooperation and "community" fedora people against it.
On Thursday 01 February 2007 02:39, Ralf Corsepius wrote:
Exactly this is the point, I am asking: Why explicitly care about jpp?
The reason we explicitly care about jpackage is because our (Red Hat's) java folks do _all_ of their packaging upstream at jpackage, and just import the results downstream within RHEL and Fedora. This workflow allows them to manage far more java packages than if they were to do it on their own within RH/Fedora. We would like to enable them to continue this, with jpackage being the defacto standard for java packaging, we just import what they do as other distributions can and do.
There isn't much that prevents other packagers from doing this with their upstreams, so long as they adhere to the guidelines. We had to create some special cases for jpackage due to how their upstream works and a somewhat unresolvable clash with our guidelines. We'd rather not have to do this, but in this case it seemed unavoidable.
Personally I don't like it, and I'll fight tooth/nail against any further exceptions like this, but I did see the need for us to have java packages in Fedora.
On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-01-30 at 17:30 -0800, Toshio Kuratomi wrote:
On Tue, 2007-01-30 at 18:40 -0600, Tom 'spot' Callaway wrote:
On Tue, 2007-01-30 at 18:17 -0600, Jason L Tibbitts III wrote:
>>> "TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> This exception documents how Java packages which come from TC> JPackage are to be handled, and paves the way for the eventual TC> removal of the jpp tag.
I have no problem with granting the exception, but I do think the definition of the exception should include a explicitly state the conditions under which it will go away.
The linked document has rationale and ideas for things to be added to rpm and yum under the "Proposal" section, but there's no clear statement of just how long the exception is to be granted. (Perhaps it's intended to be permanent; it's just not clear from the document.)
Unfortunately, the exception will be permanent for the Java packages from JPackage. The exception will be modified when we can safely drop the jpp tag from Fedora.
Err.. If you mean "permanent for the Java packages *in* JPackage" then I'm still okay with the proposal. Otherwise I'm changing my vote....
The Java packages in Fedora which originally come from the JPackage repo are the only packages which fall under this exception. And those packages will always fall under this exception, forever and ever, amen (or until something dramatic changes).
I'm with tibbs... The more information I get, the more confused I am :-)
I think I've realized where I'm getting confused, though. JPackage packages will always fall under this policy. However this policy only allows use of the "jpp" portion of the JPackage release tag until the technical considerations are worked out. At that point the policy will use the integer subrelease from JPackage without jpp.
If this is true then I'm still +1.
I dislike using the word Exception in something that's meant to be permanent because exceptions are things you want to get rid of. Since this is something that we're seeing a continuous value in maybe "JPackage Subrelease Policy" would be better. Use of the subrelease by itself is generic enough that we might even consider extending it to cover other situations if there's a legitimate need for it in the future.
-Toshio
On Wed, 2007-01-31 at 10:26 -0800, Toshio Kuratomi wrote:
I think I've realized where I'm getting confused, though. JPackage packages will always fall under this policy. However this policy only allows use of the "jpp" portion of the JPackage release tag until the technical considerations are worked out. At that point the policy will use the integer subrelease from JPackage without jpp.
If this is true then I'm still +1.
Yes. This is the case.
I dislike using the word Exception in something that's meant to be permanent because exceptions are things you want to get rid of. Since this is something that we're seeing a continuous value in maybe "JPackage Subrelease Policy" would be better. Use of the subrelease by itself is generic enough that we might even consider extending it to cover other situations if there's a legitimate need for it in the future.
Agreed. I'll rename it accordingly when it gets out of Draft.
~spot
On Tue, Jan 30, 2007 at 02:46:12PM -0600, Tom 'spot' Callaway wrote:
OK guys, here's the item that I've been working on with the JPackage folks for a while:
http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
This exception documents how Java packages which come from JPackage are to be handled, and paves the way for the eventual removal of the jpp tag.
Fernando Nasser, Jesse Keating, and many others helped me put this together, and they all seem pretty happy with what we've got in this final draft.
FPC members: Please vote on this item.
Thanks,
~spot
I think we can get both the upgrade paths sane and the guidelines non-violated (and in no need for exceptions) by using the proposed scheme, but drop the jpp part, e.g. from the example
|| '''JPackage''' || '''Fedora Package''' || '''Status''' || '''Highest RPMver''' || || javacc-4.0-3jpp.src.rpm || javacc-4.0-3.1.fc7.src.rpm || Package merged from JPackage into Fedora devel || Fedora || || javacc-4.0-3jpp.src.rpm || javacc-4.0-3.2.fc7.src.rpm || Fedora package has a bug fixed, bump subrelease || Fedora || || javacc-4.0-3jpp.src.rpm || javacc-4.0-3.3.fc7.src.rpm || Fedora package is rebuilt for new gcc, bump subrel || Fedora || || javacc-4.0-4jpp.src.rpm || javacc-4.0-3.3.fc7.src.rpm || JPackage is updated to fix a bug, bumps major release || JPackage || || javacc-4.0-4jpp.src.rpm || javacc-4.0-4.1.fc7.src.rpm || Fedora package is merged from new JPackage || Fedora || || javacc-5.0-1jpp.src.rpm || javacc-4.0-4.1.fc7.src.rpm || JPackage releases new version of package || JPackage || || javacc-5.0-1jpp.src.rpm || javacc-5.0-1.1.fc7.src.rpm || Fedora package is merged from new JPackage || Fedora || || javacc-5.0-1jpp.src.rpm || javacc-5.0-1.1.fc7.src.rpm || FC-7 is released, package is no longer in devel || Fedora || || javacc-5.0-1jpp.src.rpm || javacc-5.0-1.1.fc7.1.src.rpm || A bug is fixed in the FC-7 package. || Fedora ||
If s/o wants to visually emphasize the hierarchical structure in the above one could use the "_" separator, e.g. javacc-4.0-3_1.fc7.src.rpm.
Remember: numbers win over alpha in rpm, so we have ensure upgrade paths, e.g.
<X>jpp < <X>.<Y>.blah < <X+1>jpp
Furthermore I think that
| Once the Fedora package is out of the devel branch and into a | released branch, the release and subrelease fields are frozen. These | packages are now subject to the Minor release bumps for old branches | rule.
is very bad, we often explored that the space after the %{?dist} is harmful to use, and it's not neccessary either. Why not continue to use the second integer and freezing it? In the example above javacc-5.0-1.1.fc7.1.src.rpm should become javacc-5.0-1.2.fc7.src.rpm and if the bug is worth it it would even get rebuilt for FC6 (or RHEL etc).
There are still different optinions on whether using the space after the %{?dist} should be allowed or not (otherwise we'd have a part in the guidelines), but in any case the java/jpackage packages don't need it more or less than other packages, so that's not the use case to bring this up again.
Since neither of the two exceptions are really needed, I'd say -1
On Thu, Feb 01, 2007 at 07:52:51AM +0100, Axel Thimm wrote:
There are still different optinions on whether using the space after the %{?dist} should be allowed or not (otherwise we'd have a part in the guidelines)
I meant we'd have this disallowed in the guidelines, currently we do have this with a big warning. Anyway as written before it doesn't apply more to jpackage packages than any other package, so we don't even need to discuss whether it's sane or not in general (it isn't ;).
On Tuesday 30 January 2007 22:46, Tom 'spot' Callaway wrote:
http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
"According to Fernando Nasser, JPackage RPMS only use integers in the Release: field, in the format Xjpp. If this is the case, then the following format will ensure clean upgrades from Fedora to JPackage and so forth: [...]"
JPackage's pre-release Release: tags are not Xjpp only. Was this considered in the draft? Some random examples:
classpathx-jaxp-1.0-0.beta1.10jpp cpptasks-1.0-0.b4.1jpp cryptix-asn1-0.1.12-0.cvs20011119.7jpp activemq3-3.2.5-0.r1125.2jpp radeox-0.9-0.beta.2jpp
More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/
Ville Skyttä wrote:
On Tuesday 30 January 2007 22:46, Tom 'spot' Callaway wrote:
http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
"According to Fernando Nasser, JPackage RPMS only use integers in the Release: field, in the format Xjpp. If this is the case, then the following format will ensure clean upgrades from Fedora to JPackage and so forth: [...]"
JPackage's pre-release Release: tags are not Xjpp only. Was this considered in the draft? Some random examples:
classpathx-jaxp-1.0-0.beta1.10jpp cpptasks-1.0-0.b4.1jpp cryptix-asn1-0.1.12-0.cvs20011119.7jpp activemq3-3.2.5-0.r1125.2jpp radeox-0.9-0.beta.2jpp
More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/
These are old style tags, before Nicolas brought up the possible problems with upgrade paths. There is a guideline proposal on the list currently, so people choose between two (Fedora-like) numbering schemes.
You've been away for too long ;-)
On Thursday 01 February 2007 16:50, Fernando Nasser wrote:
Ville Skyttä wrote:
JPackage's pre-release Release: tags are not Xjpp only. Was this considered in the draft? Some random examples:
classpathx-jaxp-1.0-0.beta1.10jpp cpptasks-1.0-0.b4.1jpp cryptix-asn1-0.1.12-0.cvs20011119.7jpp activemq3-3.2.5-0.r1125.2jpp radeox-0.9-0.beta.2jpp
More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/
These are old style tags, before Nicolas brought up the possible problems with upgrade paths.
My point wasn't about whether they're 0.foo.Xjpp or 0.1.foo.Xjpp, but that the draft says:
"JPackage RPMS only use integers in the Release: field, in the format Xjpp"
Note: 0.foo.Xjpp is not in the Xjpp format, neither is 0.X.foo.Yjpp. For example, 1jpp and 15jpp are.
The draft goes on and says "If this is the case, then ..." and discusses how to take care of stuff. I just want to make sure the discussion is not based on a false assumption. I *guess* pre-release names like that are not a problem, but haven't read the draft too thoroughly to be able to tell at the moment.
Quite frankly, I'm a bit surprised about how much discussion and documentation and migration plans do three little "jpp" letters in the release tag really need... shrug, I really don't have an opinion beyond "if it works for and makes lifes of people working with JPackage considerably easier, and works for Fedora end users, no objections here". Dunno whether that's a +1 or 0, maybe the former.
On Thu, 2007-02-01 at 23:30 +0200, Ville Skyttä wrote:
On Thursday 01 February 2007 16:50, Fernando Nasser wrote:
Ville Skyttä wrote:
JPackage's pre-release Release: tags are not Xjpp only. Was this considered in the draft? Some random examples:
classpathx-jaxp-1.0-0.beta1.10jpp cpptasks-1.0-0.b4.1jpp cryptix-asn1-0.1.12-0.cvs20011119.7jpp activemq3-3.2.5-0.r1125.2jpp radeox-0.9-0.beta.2jpp
More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/
These are old style tags, before Nicolas brought up the possible problems with upgrade paths.
My point wasn't about whether they're 0.foo.Xjpp or 0.1.foo.Xjpp, but that the draft says:
"JPackage RPMS only use integers in the Release: field, in the format Xjpp"
Note: 0.foo.Xjpp is not in the Xjpp format, neither is 0.X.foo.Yjpp. For example, 1jpp and 15jpp are.
The draft goes on and says "If this is the case, then ..." and discusses how to take care of stuff. I just want to make sure the discussion is not based on a false assumption. I *guess* pre-release names like that are not a problem, but haven't read the draft too thoroughly to be able to tell at the moment.
Here's an attempt to resolve this::
When a jpackage package uses a prerelease, use %{fedora prerelease scheme}.Xjpp.%{rest of fedora release} where Xjpp is the integer+"jpp" portion of the jpackage release tag. Example: cpptasks-1.0-0.b4.1jpp => cpptasks-1.0-0.1.b4.1jpp.fc6[OPTIONAL .INT]
When a jpackage package uses the same prerelease scheme as Fedora, this will allow interleaving: cpptasks-1.0-0.1.b4.1jpp => cpptasks-1.0-0.1.b4.1jpp.fc6.1
If the jpackage does not there can be breakage but it's not expected that this case will arise. The important thing is for the packagers to realize that the only thing coming from the jpackage tag is 1jpp. Doing this will help catch problems if someone wants to import a JPackage with this old version scheme or a JPackage that has a buggy version string.
-Toshio
Quoting Toshio Kuratomi a.badger@gmail.com:
On Thu, 2007-02-01 at 23:30 +0200, Ville Skyttä wrote:
On Thursday 01 February 2007 16:50, Fernando Nasser wrote:
Ville Skyttä wrote:
JPackage's pre-release Release: tags are not Xjpp only. Was this considered in the draft? Some random examples:
classpathx-jaxp-1.0-0.beta1.10jpp cpptasks-1.0-0.b4.1jpp cryptix-asn1-0.1.12-0.cvs20011119.7jpp activemq3-3.2.5-0.r1125.2jpp radeox-0.9-0.beta.2jpp
More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/
These are old style tags, before Nicolas brought up the possible problems with upgrade paths.
My point wasn't about whether they're 0.foo.Xjpp or 0.1.foo.Xjpp, but that the draft says:
"JPackage RPMS only use integers in the Release: field, in the format Xjpp"
Note: 0.foo.Xjpp is not in the Xjpp format, neither is 0.X.foo.Yjpp. For example, 1jpp and 15jpp are.
The draft goes on and says "If this is the case, then ..." and discusses how to take care of stuff. I just want to make sure the discussion is not based on a false assumption. I *guess* pre-release names like that are not a problem, but haven't read the draft too thoroughly to be able to tell at the moment.
Here's an attempt to resolve this::
When a jpackage package uses a prerelease, use %{fedora prerelease scheme}.Xjpp.%{rest of fedora release} where Xjpp is the integer+"jpp" portion of the jpackage release tag. Example: cpptasks-1.0-0.b4.1jpp => cpptasks-1.0-0.1.b4.1jpp.fc6[OPTIONAL .INT]
When a jpackage package uses the same prerelease scheme as Fedora, this will allow interleaving: cpptasks-1.0-0.1.b4.1jpp => cpptasks-1.0-0.1.b4.1jpp.fc6.1
If the jpackage does not there can be breakage but it's not expected that this case will arise. The important thing is for the packagers to realize that the only thing coming from the jpackage tag is 1jpp. Doing this will help catch problems if someone wants to import a JPackage with this old version scheme or a JPackage that has a buggy version string.
-Toshio
Hi Toshio,
The new upstream JPackage scheme for pre-releases is actually based on the Fedora pre-release scheme and it is fully compatible with Fedora. Actually you seem to have guessed it right above:
xxxxx-1.0-0.X.<pre-release-tag-from-upstream>.Yjpp
where X = 1, 2, 3... and is incremented whenever the package is updated to a new pre-release tag. Rebuilds of the same sources increment the Y.
Note that CVS and SVN date tags have now been changed to follow the same Fedora rule:
YYYYMMDDcvs or YYYYMMDDsvn
Also, as the Jpackage 1.7 release is not yet final, all the packages that have wrong pre-release tags will be rebuilt. (Note: there is a slim possibility that Epoch must be raised for some package, but hopefully not).
Regards, Fernando
packaging@lists.fedoraproject.org