Re: upstream wants me to rename my package
On Fri, Sep 7, 2012 at 10:54 PM, Gary Gatling wrote: > If a upstream project somehow objects to someone packaging their software > should you just give up and tell people that the upstream would prefer you > download their self created rpms or is it considered acceptable to go ahead > and package their software over their objections? > > > He says at the end of his email: > > "'I'm willing to help out in any way I can, within reason, but I will also > re-iterate that VirtualGL was never really designed to be integrated > into an O/S distribution." > > Thanks for any thoughts you guys might have about this surprising > reaction... The classic 0.02: Now, I don't really get the "not designed to be integrated in a distro" part, but since he obviously wants to offer RPMs for his project, maybe he could be interested in becoming the (co)maintainer in Fedora? Being in the distro's official repo has several advantages (exposure, easy installation, etc) that any upstream should be very keen about. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
I don't see the reason for someone to install and use two versions of the same thing and I think that renaming the package other than project name is a bad idea... Besides that, if the developer doesn't want that others redistribuite his program he can always change the license or become co-maintainer of the package in fedora repos. Il 07/09/2012 22:54, Gary Gatling ha scritto: Hello, I am working on a package called VirtualGL: https://bugzilla.redhat.com/show_bug.cgi?id=834127 After contacting the upstream on their mailing list, they seem obsessed with being able to install their own rprms and my package together at the same time. This seems odd / bad to me since only one vglrun could be in the path. He keeps talking about using symlinks in /opt and so forth to to somehow make my package able to co-exists with his package downloadable at: http://www.virtualgl.org/ He does want me to change the package name also. Is it too late for me to that after that package has been accepted into fedora? Here is what he says about that: In terms of naming, I would suggest naming your RPM something besides VirtualGL. If you are splitting it into multiple RPMs, then this is easy. Just ship RPMs named "VirtualGL-common", "VirtualGL-client", "VirtualGL-utils", "VirtualGL-server", "VirtualGL-devel", etc., and none of them will actually be named "VirtualGL". Or maybe use "VirtualGL-fedora" or some alternative (even lowercase "virtualgl", perhaps.) If a upstream project somehow objects to someone packaging their software should you just give up and tell people that the upstream would prefer you download their self created rpms or is it considered acceptable to go ahead and package their software over their objections? He says at the end of his email: "'I'm willing to help out in any way I can, within reason, but I will also re-iterate that VirtualGL was never really designed to be integrated into an O/S distribution." Thanks for any thoughts you guys might have about this surprising reaction... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Alpha Test Compose 6 (TC6) Available Now!
2012/9/6 Andre Robatino : > As per the Fedora 18 schedule [1], Fedora 18 Alpha Test Compose 6 (TC6) > is now available for testing. Content information, including changes, > can be found at https://fedorahosted.org/rel-eng/ticket/5284#comment:13 > . Please see the following pages for download links (including delta > ISOs) and testing instructions. Normally dl.fedoraproject.org should > provide the fastest download, but download-ib01.fedoraproject.org is > available as a mirror (with an approximately 1 hour lag) in case of > trouble. To use it, just replace "dl" with "download-ib01" in the > download URL. > > Installation: > > https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test > > Base: > > https://fedoraproject.org/wiki/Test_Results:Current_Base_Test > > Desktop: > > https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test > > Ideally, all Alpha priority test cases for Installation [2], Base [3], > and Desktop [4] should pass in order to meet the Alpha Release Criteria > [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the > test list [7]. > > Create Fedora 18 Alpha test compose (TC) and release candidate (RC) > https://fedorahosted.org/rel-eng/ticket/5284 > > Current Blocker and NTH bugs: > http://qa.fedoraproject.org/blockerbugs/current > > F18 Alpha Blocker tracker bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752654 > > F18 Alpha Nice-To-Have tracker bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752662 > > [1] http://jreznik.fedorapeople.org/schedules/f-18/f-18-quality-tasks.html > [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing > [3] https://fedoraproject.org/wiki/QA:Base_validation_testing > [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing > [5] https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria > [6] irc://irc.freenode.net/fedora-qa > [7] https://admin.fedoraproject.org/mailman/listinfo/test > > > ___ > test-announce mailing list > test-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/test-announce > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC6/Live/i386/ Are those TC5 images hosted there? Or just mislabeled? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
On Fri, 7 Sep 2012, Ken Dreyer wrote: With VirtualGL, if his main concern is that Fedora's RPMs will overwrite the ones that he sells, could he just bump the Epoch tag in his copies? This is exactly what I did with custom rpms for opendnssec that depended on proprietary PKCS#11 drivers and some different dependancies. I set the epoch to 42 and that's what they have in their private repo. It will never conflict with their RHEL/EPEL repositories. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On 09/07/2012 03:34 PM, Dan Williams wrote: And here comes the bigger question what is keeping all you networking guys from simply combine all that effort and coming up with one single network application that everybody can use happily from embedded to servers to desktop? There's room to work towards consensus on functionality, but at the moment I don't see a lot of momentum towards a Grand New Unified Plan, partially because that's how free software works. It would be great if we had one, and I'm certainly willing to entertain changes to NetworkManager that make it more capable for anyone's use-cases. Nobody thinks NM has reached perfection, least of all me. As someone who recently needed some pretty niche functionality if you ask me. I was amazed at the amount of help and open-mindedness of Dan. He helped me learn where stuff was in the tree, and gave me pseudo code. Walked me through some parts and spoon fed me other pieces of code necessary to make what I needed happen with NM. It was then merged into NetworkManager. Of any project that could potentially do all the things that are necessary, I'd vote for NM. It'd be a shame that the other projects couldn't work together towards a common goal. I can't imagine how it wouldn't be possible to get NM to the point where it does do everything one needs it to do. Especially with the lead developers it has. My 2cents. -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstream wants me to rename my package
Hey guys, I decided to ask if he would be willing to add an epoc tag as Ken suggested or be willing to become a maintainer or co-maintainer. I think he just continues to insist that rpm work in a way its not designed... (Have two versions of the same software thing on a box) Here is his response in full: On Sun, Sep 9, 2012 at 12:38 AM, DRC wrote: To be clear, I don't sell software. The official VirtualGL RPMs are provided for free on SourceForge, but I pay my rent through support, professional services, and funded development of VirtualGL and other OSS projects (libjpeg-turbo, TurboVNC, libvncserver, etc. etc.) The ability to do just-in-time distribution of binaries (via the VirtualGL Pre-Releases page on VirtualGL.org) is part and parcel of these professional services. A customer reports a bug, and I can often turn around a new build for them within hours. These customers are typically large installations-- sometimes hundreds of seats-- so when they get a new RPM from me, they test it in isolation and then push it out to their users via their own internal distribution mechanism. They would not use YUM, even if VirtualGL was provided via that mechanism. The VirtualGL Project has been shipping RPMs for 8 years now, so I'm understandably hesitant to change the name of our packages just to make a downstream O/S distributor happy. For consistency, I'd have to change the name of all of the packages-- Windows, Mac, Debian, etc. PITA. The concern is not really that Fedora will overwrite our RPMs. The official VirtualGL RPMs use a build number based on the date (such as 20120908), so our RPMs will likely overwrite Fedora's, which use a build number of 1, 2, etc. Using a higher epoch number with our packages is certainly easy enough to do as well, to really guarantee that our packages will clobber theirs. However, what I'm really trying to achieve is the ability to install our package alongside the distribution-supplied package. The idea is that a user may be using the distribution-supplied version for day-to-day work, but they may need to install a pre-release to test a new fix, or to temporarily use a pre-release until a fix is deployed via YUM. It would be nice for them to be able to do that without uninstalling the distribution-supplied version. Also, the distribution-supplied version may support features (such as OpenSSL) that we don't build into the official binaries. I'm willing to meet halfway on this-- to move all of the official VirtualGL files into /opt/VirtualGL and to use alternatives to install links in /usr/bin. However, I'm not willing to change the name of the package at this time, so if Fedora isn't willing to do that, either, or if they aren't willing to play nice in /usr/bin, then a conflict is inevitable. If a conflict is inevitable, then there's no real point to me putting forth any effort to re-organize things on my end. I'm still willing to make minor changes to make things easier on you, as long as they don't make things harder on me. It would still be nice to figure out how to pre-load the libraries from a non-system directory in a generic way, for instance. To answer your second question, no, I do not have time to become a package maintainer. Frankly, what's in it for me? At the end of the day, the only real benefit I would see from having VirtualGL distributed by a major O/S is publicity, and the potential upside to that is not worth the downside of completely re-engineering our packaging system. I also do not want to get into the business of supporting distribution-specific VirtualGL releases. I designed our official packages to provide as uniform a layout as possible to make things easier on me. Trying to support several different distribution-specific layouts makes things a lot harder for me. So a question would be do I need to jump through more hoops so that: " ...a user may be using the distribution-supplied version for day-to-day work, but they may need to install a pre-release to test a new fix, or to temporarily use a pre-release until a fix is deployed via YUM. It would be nice for them to be able to do that without uninstalling the distribution-supplied version. Also, the distribution-supplied version may support features (such as OpenSSL) that we don't build into the official binaries." ? So I guess another question is what is our official response? I am trying to follow Ken's suggestion but anything I say just makes him more insistent and possibly hostile... My suggestion is that we name the package "virtualgl" (all lowercase) since thats still technically the name of the software. I think caps are kind of stupid in a package name anyways? I'm not sure what to say about "alternatives" but I'm not trying to piss them off either. :) Thoughts? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
