Re: What to do about packaging beta, or rc as alternate installable
On Thu, 2014-01-23 at 19:19 -0700, Pete Travis wrote: > Is there something inherent to COPRs that solves the problem of > duplicate paths, ie /usr/bin/mercurial from two different sources? > > If I missed something, a link with an appropriate measure of mocking > would be welcome. Not AFAIK. If you want your test package to be parallel installable, you'd have to do the usual work of changing its install location or prefixing/suffixing its names or whatever. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Jan 23, 2014 1:12 PM, "Stephen Gallagher" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/23/2014 01:43 PM, Kevin Kofler wrote: > > Christopher Meng wrote: > >> But you can do this on copr IMO. Also update-testing is not just > >> a place for updates to have a break, you can let it satisfy the > >> needs of testing for unstable. > > > > Well, that's kinda abusing updates-testing. IMHO, COPR is the much > > better option until you have something reasonably close to going > > stable. > > > > The other problem with using updates-testing in this way is that it > makes it more difficult if you have to deliver a real bug or security > fix to stable. Now you have to unpush your testing version, mangle > your git history, file a new update ... > > > I agree with Kevin that this is pretty much exactly what COPR is good > at (and what I'm using it for myself[1]). > > 1) http://copr.fedoraproject.org/coprs/sgallagh/ReviewBoard2/ > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlLhd8QACgkQeiVVYja6o6N1WgCgqGU51RjTv4/uizYPOV5HSBhE > WFkAoLAl4Twg3iHIBgEx1O5++juLlaXH > =rNyt > -END PGP SIGNATURE- > -- Is there something inherent to COPRs that solves the problem of duplicate paths, ie /usr/bin/mercurial from two different sources? If I missed something, a link with an appropriate measure of mocking would be welcome. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Jan 24, 2014 7:14 AM, "Adam Williamson" wrote: > In other words: Christopher, if you're currently doing this, please move > the packages to a COPR or other venue more appropriate for this purpose, > and stop doing it. No absolutely not. I don't have any thing *unstable*. Something unstable are pushed to Archlinux AUR first. XD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Thu, 2014-01-23 at 15:11 -0800, Adam Williamson wrote: > On Thu, 2014-01-23 at 19:43 +0100, Kevin Kofler wrote: > > Christopher Meng wrote: > > > But you can do this on copr IMO. Also update-testing is not just a place > > > for updates to have a break, you can let it satisfy the needs of testing > > > for unstable. > > > > Well, that's kinda abusing updates-testing. IMHO, COPR is the much better > > option until you have something reasonably close to going stable. > > It's not just kinda abusing updates-testing, *it is abusing > updates-testing*. updates-testing has a specific and explicitly > specified purpose: to test updates before they go to -stable. That is > all that it is for. Anything in updates-testing must be something that > the maintainer expects to submit to stable once testing has indicated > that it works correctly. In other words: Christopher, if you're currently doing this, please move the packages to a COPR or other venue more appropriate for this purpose, and stop doing it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Thu, 2014-01-23 at 19:43 +0100, Kevin Kofler wrote: > Christopher Meng wrote: > > But you can do this on copr IMO. Also update-testing is not just a place > > for updates to have a break, you can let it satisfy the needs of testing > > for unstable. > > Well, that's kinda abusing updates-testing. IMHO, COPR is the much better > option until you have something reasonably close to going stable. It's not just kinda abusing updates-testing, *it is abusing updates-testing*. updates-testing has a specific and explicitly specified purpose: to test updates before they go to -stable. That is all that it is for. Anything in updates-testing must be something that the maintainer expects to submit to stable once testing has indicated that it works correctly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 01:43 PM, Kevin Kofler wrote: > Christopher Meng wrote: >> But you can do this on copr IMO. Also update-testing is not just >> a place for updates to have a break, you can let it satisfy the >> needs of testing for unstable. > > Well, that's kinda abusing updates-testing. IMHO, COPR is the much > better option until you have something reasonably close to going > stable. > The other problem with using updates-testing in this way is that it makes it more difficult if you have to deliver a real bug or security fix to stable. Now you have to unpush your testing version, mangle your git history, file a new update ... I agree with Kevin that this is pretty much exactly what COPR is good at (and what I'm using it for myself[1]). 1) http://copr.fedoraproject.org/coprs/sgallagh/ReviewBoard2/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLhd8QACgkQeiVVYja6o6N1WgCgqGU51RjTv4/uizYPOV5HSBhE WFkAoLAl4Twg3iHIBgEx1O5++juLlaXH =rNyt -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
Christopher Meng wrote: > But you can do this on copr IMO. Also update-testing is not just a place > for updates to have a break, you can let it satisfy the needs of testing > for unstable. Well, that's kinda abusing updates-testing. IMHO, COPR is the much better option until you have something reasonably close to going stable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Tue, Jan 21, 2014 at 07:33:40PM -0500, Neal Becker wrote:
> One of the packages I maintain is mercurial. Frequently (e.g., now), there
> is a rc version available for test. It will probably break some other package
> that depends on it.
>
> I am thinking of a model like google uses for chrome. I could install any of:
>
> google-chrome-{stable,beta,unstable}
>
> I don't think fedora uses this model anywhere. AFAICT, in Fedora there is
> always only 1 version available - although there could be one in updates-
> testing. But the purpose of updates-testing is now for a long-lived parallel
> development - it is designed for short term before promotion to stable.
>
> Although the google-chrome model is perhaps not the ideal way to handle the
> idea of alternative versions - it seems good enough.
>
> Any thoughts?
virt-preview is another model you might look at.
Some time (hopefully soon) we'll be building virt-preview using copr,
but for the time being you can read about it here:
https://fedoraproject.org/wiki/Virtualization_Preview_Repository
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Tue, 2014-01-21 at 19:33 -0500, Neal Becker wrote:
> One of the packages I maintain is mercurial. Frequently (e.g., now), there
> is a rc version available for test. It will probably break some other package
> that depends on it.
>
> I am thinking of a model like google uses for chrome. I could install any of:
>
> google-chrome-{stable,beta,unstable}
>
> I don't think fedora uses this model anywhere. AFAICT, in Fedora there is
> always only 1 version available - although there could be one in updates-
> testing.
Just for the record, of course we can have multiple different packages
that contain different versions of the same source. This is permitted in
specific situations, but generally frowned upon: details are in the
guidelines. It's most commonly used to provide multiple versions of
libraries where we really want to have packages that depend on different
versions of the library.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Jan 22, 2014 10:03 AM, "Mauricio Tavares" wrote: > Still, it makes sense to have a place to beta test either the > package or the packaging (how to create a proper package?) itself. It's hard to say how to create a proper package testing in one slot of pkgdb. Also it may be a burden when you don't have enough time to contribute. But you can do this on copr IMO. Also update-testing is not just a place for updates to have a break, you can let it satisfy the needs of testing for unstable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Tue, 2014-01-21 at 21:03 -0500, Mauricio Tavares wrote: > On Tue, Jan 21, 2014 at 8:58 PM, Christopher Meng wrote: > > Seriously, it's harmful to provide unstable packages to users. > > > Still, it makes sense to have a place to beta test either the > package or the packaging (how to create a proper package?) itself. That would be an ideal use for a copr or fedorapeople repo. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Tue, Jan 21, 2014 at 8:58 PM, Christopher Meng wrote: > Seriously, it's harmful to provide unstable packages to users. > Still, it makes sense to have a place to beta test either the package or the packaging (how to create a proper package?) itself. > And I don't think Fedora has a long term support. > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
Seriously, it's harmful to provide unstable packages to users. And I don't think Fedora has a long term support. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
On Tue, Jan 21, 2014 at 7:33 PM, Neal Becker wrote:
> One of the packages I maintain is mercurial. Frequently (e.g., now), there
> is a rc version available for test. It will probably break some other package
> that depends on it.
>
> I am thinking of a model like google uses for chrome. I could install any of:
>
> google-chrome-{stable,beta,unstable}
>
> I don't think fedora uses this model anywhere. AFAICT, in Fedora there is
> always only 1 version available - although there could be one in updates-
> testing. But the purpose of updates-testing is now for a long-lived parallel
> development - it is designed for short term before promotion to stable.
>
> Although the google-chrome model is perhaps not the ideal way to handle the
> idea of alternative versions - it seems good enough.
>
> Any thoughts?
You could provide it in a copr. That is what e.g. Ryan Lerch does
with unreleased builds of his corebird package.
http://copr.fedoraproject.org/
josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What to do about packaging beta, or rc as alternate installable
One of the packages I maintain is mercurial. Frequently (e.g., now), there
is a rc version available for test. It will probably break some other package
that depends on it.
I am thinking of a model like google uses for chrome. I could install any of:
google-chrome-{stable,beta,unstable}
I don't think fedora uses this model anywhere. AFAICT, in Fedora there is
always only 1 version available - although there could be one in updates-
testing. But the purpose of updates-testing is now for a long-lived parallel
development - it is designed for short term before promotion to stable.
Although the google-chrome model is perhaps not the ideal way to handle the
idea of alternative versions - it seems good enough.
Any thoughts?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
