Re: FESCo meeting summary for 2009-07-31
Le vendredi 31 juillet 2009 à 16:47 -0400, Josh Boyer a écrit : On Sat, Aug 01, 2009 at 02:00:10AM +0530, Rahul Sundaram wrote: On 08/01/2009 01:31 AM, Josh Boyer wrote: It is a random upstream project but one developed within Fedora and Fedora can and should tell them not to do so. Why shouldn't we? Again they don't need or deserve special exceptions. Treat them like any other upstream project. That is all I ask. No. That is part of the problem with your proposal. You have targetted RH or Fedora packages that do this. If some other package only distributes via SRPM (or .deb, or ebuild), they aren't required to comply. Why force these RH/Fedora packages to do something that we don't force other packages to? Because we have higher standards and our « mission is to lead the advancement of free and open source software and content as a collaborative community. ». Providing easy to find code tarballs is part of making community collaboration easy. (You can provide other means but this is the minimum requirement) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
Le vendredi 31 juillet 2009 à 13:09 -0700, Jesse Keating a écrit : On Sat, 2009-08-01 at 01:20 +0530, Rahul Sundaram wrote: That's kind of side tracking though. Point is that SRPM as upstream source is simply a stupid thing. We would complain loudly or atleast whine about it if Novell or Mandriva or Debian did that. Wouldn't we? Why should we have an exception anymore? I can't think of a single reason why we should. If there was no public available source repo, yes we'd complain. If there was, I don't think we'd complain really. Well I can tell you packaging Droid fonts is a giant PITA because they don't provide tarballs and you have to scrape files from their gitweb (and then check them one by one because they overwrite them at each code dump regardless if they changed or not) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, Jul 31, 2009 at 12:44:52PM -0700, Jesse Keating wrote: On Sat, 2009-08-01 at 00:58 +0530, Rahul Sundaram wrote: I don't think anybody is going to argue that extracting source from srpm or pulling tarball + patches from our package cvs is ideal. So I don't see why we should continue have a lame exception. Yeah, it's not idea. They should just pull it from our upstream source repo by the tag we apply when we make the release we package. Then they're much better setup to provide patches back to us in a preferred manner. Lets start moving beyond the tarball crap. Is there already support for this in rpmbuild? Can I use a SCM url as Source0 in spec files? This would be off course very useful. Regards Till pgphQsA1bfMpv.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, Jul 31, 2009 at 4:09 PM, Jesse Keatingjkeat...@redhat.com wrote: If there was no public available source repo, yes we'd complain. If there was, I don't think we'd complain really. ugh, found this in my drafts from yesterday I think (correct me if I'm wrong) is that this exception was originally designed for s-c-*, where there was no publicly available SCM (until they migrated to 108 and then fedorahosted). We already have guidelines for building from SCM, thereby making us the canonical tarball release, so I don't think this exception is required any longer myself -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Sat, Aug 1, 2009 at 4:13 AM, Till Maasopensou...@till.name wrote: Is there already support for this in rpmbuild? Can I use a SCM url as Source0 in spec files? This would be off course very useful. The only requirement for Source0 is that the last element in a URL point to a valid tarball, zipfile, whatever in %_topdir/SOURCES. If you can get that out of an SCM URL, more power to ya :) There are procedures for SCM as the canonical source, however. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESCo meeting summary for 2009-07-31
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting.2009-07-31-16.59.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting.2009-07-31-16.59.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting.2009-07-31-16.59.log.html 16:59:31 jds2001 #startmeeting FESCo meeting 7/31/09 16:59:33 jds2001 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 16:59:40 * nirik is here. 16:59:51 * pingou around 16:59:53 * sharkcz here 17:00:05 * jwb is here 17:00:14 Kevin_Kofler Present. 17:01:00 jds2001 sorry for the false alarm re: lunch 17:01:02 * dgilmore is here 17:01:07 * skvidal is here 17:01:09 jds2001 got the food to go :) 17:01:17 jds2001 anyhow, let's get started 17:01:35 jds2001 #topic mikeb as sponsor 17:01:40 jds2001 .fesco 211 17:01:52 jds2001 looks like he withdrew his request. 17:01:52 dgilmore +1 17:01:52 * notting is here 17:02:26 nirik I disagree that we should base this on quantity. I think that him doing more reviews to gain visibility and prove his understanding would be good too tho. 17:02:29 jds2001 but that being said, I'd still be +1 17:02:32 dgilmore because of the nosie made about it 17:02:47 jds2001 yes, same here, i dont think that quantity is a good indicator. 17:03:14 jwb he withdrew his request 17:03:22 dgilmore he did 17:03:25 jds2001 he also mentioned a desire to work on the backlog 17:03:26 dgilmore move on 17:03:26 nirik so, lets ask him to reapply in a month or something... 17:03:31 jds2001 yeah 17:03:33 Kevin_Kofler Well, feedback from the sponsors list was overwhelmingly negative. 17:03:45 jds2001 based on quantity 17:03:49 Kevin_Kofler If you think sponsors are basing their feedback on the wrong criteria, we need to get the criteria fixed. 17:03:52 jds2001 based on flawed criteria. 17:04:17 tibbs Please don't ask our opinions if you don't like the answers you receive. 17:04:17 Kevin_Kofler Or rather, clearly defined, because it seems they aren't. 17:04:36 jds2001 they aren't. And they shouldn't be. 17:04:57 jds2001 it's a subjective thing, really 17:05:01 Kevin_Kofler I agree with tibbs, it's ridiculous to ask for feedback from the sponsors and then to ignore it. 17:05:02 tibbs So you won't define criteria, but yet you can easily say that someone else's criteria are flawed? 17:05:02 * nirik notes there was only one -1 17:05:04 jwb jds2001, then you can't really say their criteria is flawed 17:05:10 tibbs That's really a poor method of argumentation. 17:05:30 Kevin_Kofler And saying they're basing their decision on flawed criteria doesn't make sense when there are no criteria defined at all. 17:05:42 jds2001 tibbs: sorry, I meant that other things should be taken into account 17:05:49 nirik there was one -1 (from someone who thinks quantity is important) and a bunch of discussion about the process from various other people. 17:05:51 Kevin_Kofler So I stay with my -1 vote. 17:05:54 * jds2001 notes the feedback was based on quantiy of reviews. 17:06:07 jds2001 solely, and nothing else. 17:06:17 skvidal umm 17:06:27 skvidal why are we discussing a withdrawn item? 17:06:29 Kevin_Kofler nirik: What you call discussion was I agree to the person saying -1. 17:06:30 skvidal let's move along 17:06:44 jds2001 agreed. 17:06:49 Kevin_Kofler And I think I've seen more than one explicit -1 too, but I may be remembering wrong. 17:07:07 jds2001 #topic Fedora packages as canonical upstreams 17:07:11 nirik Kevin_Kofler: I just reread the thread. Thats the only -1. ;) anyhow... 17:07:11 jds2001 .fesco 210 17:07:29 tibbs This was proposed to FPC, but it's not really FPC's decision. 17:07:45 jds2001 so there's some sticky situations here. 17:07:46 Kevin_Kofler -1 to removing the exception, it makes no sense. 17:07:58 jds2001 If there is code, then the exception needs to be removed. 17:08:07 jwb jds2001, huh? 17:08:14 Kevin_Kofler There are plenty of upstreams with no tarballs, only some SCM, some SRPMs or other source packages etc. 17:08:16 jds2001 If there's not, then it can stay (I particularly looked at basesystem) 17:08:18 nirik what would be valid as a upstream here? a fedorapeople link? 17:08:32 jds2001 nirik: or a fedorahosted project 17:08:36 jds2001 nothing extravagant 17:08:38 Kevin_Kofler There are also plenty of upstreams which just dump a tar.bz2 into some directory. 17:08:43 jds2001 but basesystem has nothing. 17:08:45 nirik so this is saying that every package needs a Source0: that is a url? 17:08:51 jwb Kevin_Kofler, those aren't want this is about... 17:08:51 Kevin_Kofler If we do that, is that really more helpful than just having it in the SRPM? 17:08:55 jds2001 nirik: thats how i read it. 17:08:56 tibbs We complain when suse makes you pull sources out of one of their packages. 17:09:04 jwb Kevin_Kofler, ah, i see where you are going 17:09:07 Kevin_Kofler jwb: Why should we be held to higher standards than other upstreams? 17:09:13 jwb right, got it now
Re: FESCo meeting summary for 2009-07-31
[..] 17:45:48 Kevin_Kofler As for killing multilibs, a proposal for next week: restrict multilibs to wine, redhat-lsb and their dependencies. Rationale: way too much stuff which will never be needed multilib is multilib. The people who really need that stuff should just use the i?86 repo and deal with the conflicts. 17:46:08 nirik Kevin_Kofler: write up a proposal. ;) Sure making the life harder for our users just deal with conflicts is the way to go... If there are issues with multilib (there are!) we should work on fixing them instead of making the user experience even worse. (if you want a pure 64 bit system that is what you get by _DEFAULT_ anyway, so no flamewars about that please.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, Jul 31, 2009 at 09:12:24PM +0200, drago01 wrote: [..] 17:45:48 Kevin_Kofler As for killing multilibs, a proposal for next week: restrict multilibs to wine, redhat-lsb and their dependencies. Rationale: way too much stuff which will never be needed multilib is multilib. The people who really need that stuff should just use the i?86 repo and deal with the conflicts. 17:46:08 nirik Kevin_Kofler: write up a proposal. ;) Sure making the life harder for our users just deal with conflicts is the way to go... If there are issues with multilib (there are!) we should work on fixing them instead of making the user experience even worse. (if you want a pure 64 bit system that is what you get by _DEFAULT_ anyway, so no flamewars about that please.) Slight correction. That is what you get by default on x86_64. Not i[3456]86 (obviously) or ppc (which is less obvious given that ppc is used on ppc64 machines). This point has nothing to do with what you were actually saying though. So feel free to ignore it as a clarification, not a rebuttal. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On 08/01/2009 12:18 AM, Jon Stanley wrote: Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting.2009-07-31-16.59.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting.2009-07-31-16.59.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting.2009-07-31-16.59.log.html I have edited the proposal a bit to clarify things https://fedoraproject.org/wiki/No_more_exception_where_we_are_upstream%28draft%29 I don't think anybody is going to argue that extracting source from srpm or pulling tarball + patches from our package cvs is ideal. So I don't see why we should continue have a lame exception. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, 31 Jul 2009 14:48:02 -0400, Jon wrote: Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting.2009-07-31-16.59.log.html http://portaudio.com/trac/log/portaudio/trunk/src/hostapi/alsa/pa_linux_alsa.c?rev=1412 The patch has also been merged by Audacity meanwhile during a sync with portaudio upstream, so the most recent Fedora packages do not apply the separate patch anymore either. During the F9/F10 timeframe, Audacity without the patch worked for enough users. With regard to discussing whether the system portaudio library could be used for Audacity, I recommend people first become familiar with the level of patching done by Audacity's developers to their local copy of portaudio. In particular, the feature called PortMixer is part of Audacity for a long time and has not been merged by PortAudio upstream. A feature would get lost by forcing Audacity to use the system library. A patch to do that has been rejected on audacity-devel list just recently. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Sat, 2009-08-01 at 00:58 +0530, Rahul Sundaram wrote: I don't think anybody is going to argue that extracting source from srpm or pulling tarball + patches from our package cvs is ideal. So I don't see why we should continue have a lame exception. Yeah, it's not idea. They should just pull it from our upstream source repo by the tag we apply when we make the release we package. Then they're much better setup to provide patches back to us in a preferred manner. Lets start moving beyond the tarball crap. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On 08/01/2009 01:14 AM, Jesse Keating wrote: On Sat, 2009-08-01 at 00:58 +0530, Rahul Sundaram wrote: I don't think anybody is going to argue that extracting source from srpm or pulling tarball + patches from our package cvs is ideal. So I don't see why we should continue have a lame exception. Yeah, it's not idea. They should just pull it from our upstream source repo by the tag we apply when we make the release we package. Then they're much better setup to provide patches back to us in a preferred manner. Lets start moving beyond the tarball crap. That's kind of side tracking though. Point is that SRPM as upstream source is simply a stupid thing. We would complain loudly or atleast whine about it if Novell or Mandriva or Debian did that. Wouldn't we? Why should we have an exception anymore? I can't think of a single reason why we should. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Sat, 2009-08-01 at 01:20 +0530, Rahul Sundaram wrote: That's kind of side tracking though. Point is that SRPM as upstream source is simply a stupid thing. We would complain loudly or atleast whine about it if Novell or Mandriva or Debian did that. Wouldn't we? Why should we have an exception anymore? I can't think of a single reason why we should. If there was no public available source repo, yes we'd complain. If there was, I don't think we'd complain really. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On 08/01/2009 01:31 AM, Josh Boyer wrote: Source0: http://cvs.fedoraproject.org/lookaside/pkgs/anaconda/anaconda-11.5.0.59.tar.bz2/0b0b7b30f1ff03bad05bda3d052b73a8/anaconda-11.5.0.59.tar.bz2 is really no better. This would ridiculous. I don't think any project is going to do this. Even if they do want to go to this extend, we don't need to grant them special exceptions. We can recommend that the projects used a proper project hosting facility and leave it at that. I All you are doing is forcing people to list a URL. Also, if an upstream project doesn't want to host all that and wants to use the SRPM as the source, who is Fedora to tell them they can't? It is a random upstream project but one developed within Fedora and Fedora can and should tell them not to do so. Why shouldn't we? Again they don't need or deserve special exceptions. Treat them like any other upstream project. That is all I ask. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On 08/01/2009 01:39 AM, Jesse Keating wrote: On Sat, 2009-08-01 at 01:20 +0530, Rahul Sundaram wrote: That's kind of side tracking though. Point is that SRPM as upstream source is simply a stupid thing. We would complain loudly or atleast whine about it if Novell or Mandriva or Debian did that. Wouldn't we? Why should we have an exception anymore? I can't think of a single reason why we should. If there was no public available source repo, yes we'd complain. If there was, I don't think we'd complain really. Remove the special exception and the projects can deal with it the way they want. If they provide a source repo, that would be following good upstream practises. If they go and link to the package cvs, then they are just being deliberately lame. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Sat, Aug 01, 2009 at 02:00:10AM +0530, Rahul Sundaram wrote: On 08/01/2009 01:31 AM, Josh Boyer wrote: Source0: http://cvs.fedoraproject.org/lookaside/pkgs/anaconda/anaconda-11.5.0.59.tar.bz2/0b0b7b30f1ff03bad05bda3d052b73a8/anaconda-11.5.0.59.tar.bz2 is really no better. This would ridiculous. I don't think any project is going to do this. It's no more ridiculous than forcing someone to setup a project website to host tarballs. Even if they do want to go to this extend, we don't need to grant them special exceptions. We can recommend that the projects used a proper project hosting facility and leave it at that. I This is part of the problem. Perhaps the developers don't want to be bothered with setting up a project hosting facility for something they to-date have been releasing in a manner they find sufficient. I don't see why they should be forced to just to be part of Fedora. If we want to encourage and recommend that, great! But saying it's required when they are providing sufficient means of getting the source to the package (in a Fedora perferred form even!) is a bit odd to me. All you are doing is forcing people to list a URL. Also, if an upstream project doesn't want to host all that and wants to use the SRPM as the source, who is Fedora to tell them they can't? It is a random upstream project but one developed within Fedora and Fedora can and should tell them not to do so. Why shouldn't we? Again they don't need or deserve special exceptions. Treat them like any other upstream project. That is all I ask. No. That is part of the problem with your proposal. You have targetted RH or Fedora packages that do this. If some other package only distributes via SRPM (or .deb, or ebuild), they aren't required to comply. Why force these RH/Fedora packages to do something that we don't force other packages to? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, Jul 31, 2009 at 01:09:43PM -0700, Jesse Keating wrote: On Sat, 2009-08-01 at 01:20 +0530, Rahul Sundaram wrote: That's kind of side tracking though. Point is that SRPM as upstream source is simply a stupid thing. We would complain loudly or atleast whine about it if Novell or Mandriva or Debian did that. Wouldn't we? Why should we have an exception anymore? I can't think of a single reason why we should. If there was no public available source repo, yes we'd complain. If there was, I don't think we'd complain really. We don't complain about no public source repo. See deltarpm. It's repo consists of the tarball we use already. It doesn't even have an easily findable project website. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On 07/31/2009 01:01 PM, Josh Boyer wrote: On Sat, Aug 01, 2009 at 01:20:12AM +0530, Rahul Sundaram wrote: On 08/01/2009 01:14 AM, Jesse Keating wrote: On Sat, 2009-08-01 at 00:58 +0530, Rahul Sundaram wrote: I don't think anybody is going to argue that extracting source from srpm or pulling tarball + patches from our package cvs is ideal. So I don't see why we should continue have a lame exception. Yeah, it's not idea. They should just pull it from our upstream source repo by the tag we apply when we make the release we package. Then they're much better setup to provide patches back to us in a preferred manner. Lets start moving beyond the tarball crap. Where this exception comes into play, there is no upstream source repo. That's kind of side tracking though. Point is that SRPM as upstream source is simply a stupid thing. We would complain loudly or atleast whine about it if Novell or Mandriva or Debian did that. Wouldn't we? Why should we have an exception anymore? I can't think of a single reason why we should. Because doing this: Source0: http://cvs.fedoraproject.org/lookaside/pkgs/anaconda/anaconda-11.5.0.59.tar.bz2/0b0b7b30f1ff03bad05bda3d052b73a8/anaconda-11.5.0.59.tar.bz2 With the exception removed, this would violate the letter of the guidelines for new reviews but might actually be acceptable. It is better than:: Source0: 12345.tar.gz because people can browse to:: http://cvs.fedoraproject.org/lookaside/pkgs/anaconda/ and check for new anaconda packages. The reason it might violate the letter of the guidelines without the exception is that the Guidelines are designed to confirm the package comes from upstream during the review so the reviewer needs to be able to get it from somewhere and check it against what's in the SRPM. Since we are upstream, that might not matter. is really no better. All you are doing is forcing people to list a URL. This is not what removing the exception is about. Also, if an upstream project doesn't want to host all that and wants to use the SRPM as the source, who is Fedora to tell them they can't? We do for every project except those developed from within Fedora (which, in practice, seems to mean Red Hat developed software). So it's a Fedora/Red Hat development practice that would be changing. The proposal is to remove an exception from the Packaging Guidelines. Here's the text of the exception: We are Upstream For some packages where we are the upstream authors, for instance, the system-config-* tools, the source rpm that we distribute is the canonical source of the files. There is no public revision control system or publically released tarball for these programs so there is no tarball to list. Add a comment like the following to the spec: # This is a Red Hat maintained package which is specific to # our distribution. Thus the source is only available from # within this srpm. Source0: system-config-foo-1.0.tar.gz This has nothing to do with whether upstream releases tarballs or not. It just has to do with whether upstream source is available from anywhere but our srpms and lookaside. If FESCo decides not to remove the exception, it probably makes sense for FPC to update it to use the lookaside URL as that seems to be a better implementation than simply telling people to download the SRPMS. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On 08/01/2009 02:17 AM, Josh Boyer wrote: This is part of the problem. Perhaps the developers don't want to be bothered with setting up a project hosting facility for something they to-date have been releasing in a manner they find sufficient. This is a bit of circular logic. They find it sufficient because the packaging guidelines explicitly added a exception to accommodate this. Otherwise they would have bothered to do so. I don't see why they should be forced to just to be part of Fedora. Again, they are not random developers. They are part of Fedora Project. If we want to encourage and recommend that, great! But saying it's required when they are providing sufficient means of getting the source to the package (in a Fedora perferred form even!) is a bit odd to me. So a special exception doesn't sound at all? Do you think that is encouraging them to setup a proper project hosting? No. That is part of the problem with your proposal. You have targetted RH or Fedora packages that do this. If some other package only distributes via SRPM (or .deb, or ebuild), they aren't required to comply. Why force these RH/Fedora packages to do something that we don't force other packages to? I am not the one targeting Red Hat or Fedora packages. https://fedoraproject.org/wiki/Packaging:SourceURL#We_are_Upstream They were targeted in the exception which I am asking FESCo to drop. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On 07/31/2009 01:47 PM, Josh Boyer wrote: On Sat, Aug 01, 2009 at 02:00:10AM +0530, Rahul Sundaram wrote: Even if they do want to go to this extend, we don't need to grant them special exceptions. We can recommend that the projects used a proper project hosting facility and leave it at that. I This is part of the problem. Perhaps the developers don't want to be bothered with setting up a project hosting facility for something they to-date have been releasing in a manner they find sufficient. I don't see why they should be forced to just to be part of Fedora. If we want to encourage and recommend that, great! But saying it's required when they are providing sufficient means of getting the source to the package (in a Fedora perferred form even!) is a bit odd to me. This is not a Fedora preferred form. Getting upstream software out of SRPMS or .debs is more painful than getting them out of tarballs. All you are doing is forcing people to list a URL. Also, if an upstream project doesn't want to host all that and wants to use the SRPM as the source, who is Fedora to tell them they can't? It is a random upstream project but one developed within Fedora and Fedora can and should tell them not to do so. Why shouldn't we? Again they don't need or deserve special exceptions. Treat them like any other upstream project. That is all I ask. No. That is part of the problem with your proposal. You have targetted RH or Fedora packages that do this. If some other package only distributes via SRPM (or .deb, or ebuild), they aren't required to comply. Why force these RH/Fedora packages to do something that we don't force other packages to? The proposal doesn't target Fedora or RH. The exception targets Fedora or Red Hat. This removes that exception. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On 07/31/2009 01:48 PM, Josh Boyer wrote:
On Fri, Jul 31, 2009 at 01:09:43PM -0700, Jesse Keating wrote:
On Sat, 2009-08-01 at 01:20 +0530, Rahul Sundaram wrote:
That's kind of side tracking though. Point is that SRPM as upstream
source is simply a stupid thing. We would complain loudly or atleast
whine about it if Novell or Mandriva or Debian did that. Wouldn't we?
Why should we have an exception anymore? I can't think of a single
reason why we should.
If there was no public available source repo, yes we'd complain. If
there was, I don't think we'd complain really.
We don't complain about no public source repo. See deltarpm. It's repo
consists of the tarball we use already. It doesn't even have an easily
findable project website.
We're supposed to. The review for deltarpm says that the reviewer
checked the tarball against upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=202033
This is what's in the current spec:
URL: http://gitorious.org/deltarpm/deltarpm
Source: %{name}-git-20090729.tar.bz2
This doesn't follow the Guidelines but doesn't look as bad as you say.
There is a public source repo on gitorious. jdieter has commit access
there. It seems like all that's needed is the comment that says:
# Generate source by doing:
# git clone -r FF http://gitorious.org/deltarpm/deltarpm
# tar -czf deltrpm-%{version}.tar.gz deltarpm
-Toshio
signature.asc
Description: OpenPGP digital signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, 2009-07-31 at 14:17 -0700, Toshio Kuratomi wrote:
On 07/31/2009 01:48 PM, Josh Boyer wrote:
We don't complain about no public source repo. See deltarpm. It's repo
consists of the tarball we use already. It doesn't even have an easily
findable project website.
We're supposed to. The review for deltarpm says that the reviewer
checked the tarball against upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=202033
This is what's in the current spec:
URL: http://gitorious.org/deltarpm/deltarpm
Source: %{name}-git-20090729.tar.bz2
This doesn't follow the Guidelines but doesn't look as bad as you say.
There is a public source repo on gitorious. jdieter has commit access
there. It seems like all that's needed is the comment that says:
# Generate source by doing:
# git clone -r XX http://gitorious.org/deltarpm/deltarpm
# tar -czf deltrpm-%{version}.tar.gz deltarpm
FWIW, the old deltarpm web page died a while ago, but the source for
official releases has always been available at
ftp://ftp.suse.com/pub/projects/deltarpm/deltarpm-3.4.tar.bz2 (and
that's been the source tag in the spec file up until I branched off of
the new git repo last week).
I'll go ahead and fix the spec file to show where I'm getting the
current source. Sorry about the mistake.
Jonathan
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, Jul 31, 2009 at 02:06:38PM -0700, Toshio Kuratomi wrote: It is a random upstream project but one developed within Fedora and Fedora can and should tell them not to do so. Why shouldn't we? Again they don't need or deserve special exceptions. Treat them like any other upstream project. That is all I ask. No. That is part of the problem with your proposal. You have targetted RH or Fedora packages that do this. If some other package only distributes via SRPM (or .deb, or ebuild), they aren't required to comply. Why force these RH/Fedora packages to do something that we don't force other packages to? The proposal doesn't target Fedora or RH. The exception targets Fedora or Red Hat. This removes that exception. It appears I have misread the proposal as written. I've also generally made an ass out of myself here. I withdraw my objection. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, 2009-07-31 at 12:44 -0700, Jesse Keating wrote: On Sat, 2009-08-01 at 00:58 +0530, Rahul Sundaram wrote: I don't think anybody is going to argue that extracting source from srpm or pulling tarball + patches from our package cvs is ideal. So I don't see why we should continue have a lame exception. Yeah, it's not idea. They should just pull it from our upstream source repo by the tag we apply when we make the release we package. Then they're much better setup to provide patches back to us in a preferred manner. Lets start moving beyond the tarball crap. No, and no. That's what Moblin does, and you can ask Peter Robinson how much of a pain it is. If we want to ask upstreams to do tarball releases, I don't see why we should be making assertions like that. PS: Talking to Moblin guys on fixing the lack of tarballs -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Sat, Aug 1, 2009 at 1:02 AM, Bastien Nocerabnoc...@redhat.com wrote: That's what Moblin does, and you can ask Peter Robinson how much of a pain it is. If we want to ask upstreams to do tarball releases, I don't see why we should be making assertions like that. It's only a pain because Fedora's infrastructure wasn't designed for it; instead it implements the world's least optimized and most painful revision control system of series-of-tarballs. If the infrastructure supported it directly, that would change the pain equation quite a bit. There is the detail that then you'd have to know how to run autogen.sh, but jhbuild already has that knowledge for a lot of the desktop core stack. Anyways this kind of thing can be incremental; just because infrastructure now supports pulling from git doesn't mean we'd need to have a field day editing .spec files to get everything to use it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
