11:53 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For some time, the Fedora Infrastructure team and fellow community
members have been working on service upgrades for package dist-git.
This includes creating a Pagure front end like the one at
<https://pagure.io>;, a separate instance that enables forks and pull
requests on dist-git. This change solves multiple problems -- both
common, current ones, and predicted future ones -- that stymie
community growth and contribution. Examples include proposing simple
packaging fixes, changes to the dist-git branching model, and enabling
better, more continuous production models for Fedora.
These changes will *not* require packagers to change their workflows
for existing processes. Using fedpkg and git at the command line to
manage packaging will work just as before. However, it will now be
possible for other contributors to suggest changes in a
fork/pull-request model.
WE'VE TALKED ABOUT THIS FOR A LONG TIME. WHY NOW?
- -------------------------------------------------
If you've been paying attention to release tooling efforts in Fedora,
you know we're trying to accelerate the release of the Atomic Host
deliverable. Part of this effort is establishing a pipeline for
continuous integration and delivery (CI/CD) in Fedora[1]. This and
the modularity effort also are driving the establishment of services
like this dist-git front end. The hooks and capabilities of Pagure
are part of enabling CI/CD.
In early phases, these efforts will target the packages that comprise
the Atomic Host, rather than the entire universe of Fedora packages.
This temporary measure will prove out the pipeline in an open source,
iterative way. In later phases, packagers throughout Fedora will be
able to opt-in to the pipeline as well. The benefit is that we will
know more often whether a package has problems before either breaking
the distro or impacting users. In the future, we hope this will have
a positive impact on Rawhide, making it usable by more of the
community, more often.
WHAT TO EXPECT
- --------------
One of the contributions expected in this early phase is testing. The
standard interface[2] developed as part of the CI effort provides a
framework for test contributions. Shortly after Pagure/dist-git shows
up, we hope to receive test contributions from quality engineers for
packages that comprise the Atomic Host. These should come in the form
of pull requests for the package maintainers, following the
established standards.
This is a benefit for Fedora not only because it kickstarts the CI
effort, but because it provides examples the whole Fedora community
can use in later phases. The intention is that maintainers and
co-maintainers continue to control these tests so they can modify or
add to them as needed.
If you're a packager with a package in the Atomic Host, you may
receive pull requests soon after the new Pagure instance is deployed,
with these tests included. We encourage you to review and merge these
pull requests (provided they look good), so your package can take
advantage of the CI work. If you have problems with the pull request,
you can use the Pagure instance to work with the contributor to fix
it.
It is possible to turn off PRs for your dist-git repo in the repo
settings. However, we strongly encourage you to allow PRs because
this is a strong source of potential contributions with little or no
downside. We plan to work with FESCo on a project-wide policy that
makes sense and fits Fedora's values.
WANT TO TRY IT OUT?
- -------------------
If you're interested to see what this new capability looks like, and
want to test a working version, visit
<https://src.stg.fedoraproject.org/pagure/>;. Changes here won't
affect the actual Fedora RPMs, but the staging instance lets you
explore the new functionality. Note that the staging content is
updated on a schedule, so some newer package data may not appear
there.
It will be at least a few more weeks before the production instance is
ready. We appreciate your constructive feedback and bugs[3], as
always.
* * *
[1] https://fedoraproject.org/wiki/CI
[2] https://fedoraproject.org/wiki/Changes/InvokingTests
[3] https://pagure.io/pagure/issues
- --
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
-----BEGIN PGP SIGNATURE-----
iD8DBQFZXmrvrNvJN70RNxcRAv2CAJsHL66rtcFl6z/ooEOyfexkye3gBQCeOpHF
LQjAwhGOmVD2kjCD4W5Ql0c=
=AyX9
-----END PGP SIGNATURE-----
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
10:05 p.m.
On Thu, Jul 06, 2017 at 12:53:03PM -0400, Paul W. Frields wrote:
I wasn't able to log in (gateway timeout), so some impressions based
only on browsing the interface:
1. The "All projects (18686)" front page is not very useful, unless
the package you are looking for starts with digit. I think an
almost-empty lean landing with a search box in the style of google
would be more useful.
For logged-in users, the list of projects they contributed to
recently would be nice.
2. completions in search show "null" under every entry
3. The default landing page for a package shows a message about
the missing readme. Maybe we could show the %description there in
such cases?
4. releases tab shows tags. I think koji used to create those tags
when builds happened automatically, but this hasn't been happening
for a long time. (adamw yelled at me and I added a bunch manually to
systemd, but) most projects don't have any tags, or have some from
the f13-f14 era, so that content is not useful.
It would be great to get something like the "Active release overview"
from https://apps.fedoraproject.org/packages/<package> that
shows "Latest Released Version" and "Version in Testing" for each
Fedora branch. I understand this might be out of scope.
Zbyszek
8:31 a.m.
On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> <https://src.stg.fedoraproject.org/pagure/>;.
I wasn't able to log in (gateway timeout), so some impressions based
only on browsing the interface:
1. The "All projects (18686)" front page is not very useful, unless
the package you are looking for starts with digit. I think an
almost-empty lean landing with a search box in the style of google
would be more useful.
For logged-in users, the list of projects they contributed to
recently would be nice.
This is a general problem with pagure, I think -- http://pagure.io
suffers from the same issue. When you're logged in, you get projects
you own followed by forks you've created. For not logged in, There's a
sort by _age_ option, but that doesn't seem particulariy useful.
There's a ticket here https://pagure.io/pagure/issue/236... I think I'd
like to see projects sorted by activity level over the past week (but
maybe that's a lot of work for relatively little gain).
3. The default landing page for a package shows a message about
the missing readme. Maybe we could show the %description there in
such cases?
Or as an interim, show the spec file?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:19 a.m.
>>>> "MM" == Matthew Miller
<mattdm(a)fedoraproject.org> writes:
MM> Or as an interim, show the spec file?
This is actually a great opportunity for providing information about how
a package is maintained. So those with the "don't touch MY packages"
attitude have a place to document this.
But yes, it would be really great if we provide some default here, and
provide some easy way to substitute in information extracted from the
specfile or other pieces of our build process (description, active
branches, version/release info for each active branch, etc.)
I'm sure there's a lot of room for evolution here.
- J<
9:22 a.m.
On Fri, Jul 07, 2017 at 09:19:07AM -0500, Jason L Tibbitts III wrote:
MM> Or as an interim, show the spec file?
This is actually a great opportunity for providing information about how
a package is maintained. So those with the "don't touch MY packages"
attitude have a place to document this.
But yes, it would be really great if we provide some default here, and
provide some easy way to substitute in information extracted from the
specfile or other pieces of our build process (description, active
branches, version/release info for each active branch, etc.)
This might be an awful idea, but what if we have a proven packager run
a script to drop a README.md into each dist-git repo, with some default
template content (possibly including the %description)? This may be
less work than special-casing something in Pagure.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:49 a.m.
>>>> "MM" == Matthew Miller
<mattdm(a)fedoraproject.org> writes:
MM> This might be an awful idea, but what if we have a proven packager
MM> run a script to drop a README.md into each dist-git repo, with some
MM> default template content (possibly including the %description)?
Well, it's useful as a start, but I see some issues.
If not maintained automatically:
* The same data would now be kept in two places.
* Extra work for package maintainers.
* Would become outdated if maintainers don't feel like putting in extra
work.
* Would have to be set up by someone for new packages, or we're back to
the same issue on a smaller scale.
If maintained automatically:
* we must take care that any updates provided by maintainers aren't
overwritten.
* Would have to run from cron and would not be particularly cheap
(thousands of git pulls, re-substitutions and pushes) even though
these rarely change.
* Would be another task that infrastructure has to maintain, unless some
provenpackager just does this occasionally from their own
infrastructure, in which case we have to worry about how long that
person is willing to perform the task.
* The amount of scripting involved is almost certainly more than
packaging python-markdown-macros(#) and hooking that
up to pagure with a couple of custom functions to pull things from a
database which already exists.
# The markdown-macros thing I'm talking about is at
https://github.com/wnielson/markdown-macros
Of course I'm saying the latter with zero time now to actually do that,
and maybe we'd want to use a different syntax or do something custom,
but that module at least shows that it's relatively easy to do.
I'm also assuming that the existing database containing package
information is in some way accessible to the pagure instance.
MM> This may be less work than special-casing something in Pagure.
Probably slightly less work initially; I don't think pagure is so
inflexible as to require some huge restructuring to permit this.
Certainly quicker to get us to a state where we don't have blank landing
pages.
And even if we did the manual thing for a start, we can still talk about
how we'd like it to work.
- J<
4:23 a.m.
On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> 3. The default landing page for a package shows a message about
> the missing readme. Maybe we could show the %description there in
> such cases?
Or as an interim, show the spec file?
What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
The description comes from the rawhide repo via mdapi. So to update the
description, simply update the package in rawhide.
You can then simply complement these information with a README file.
Pierre
7:21 a.m.
On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
<pingou(a)pingoured.fr> wrote:
On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > 3. The default landing page for a package shows a message about
> > the missing readme. Maybe we could show the %description there in
> > such cases?
>
> Or as an interim, show the spec file?
What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
The description comes from the rawhide repo via mdapi. So to update the
description, simply update the package in rawhide.
You can then simply complement these information with a README file.
+1 that looks much better IMO
8:38 a.m.
On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
<pingou(a)pingoured.fr> wrote:
> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>> > 3. The default landing page for a package shows a message about
>> > the missing readme. Maybe we could show the %description there in
>> > such cases?
>>
>> Or as an interim, show the spec file?
>
> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>
> The description comes from the rawhide repo via mdapi. So to update the
> description, simply update the package in rawhide.
>
> You can then simply complement these information with a README file.
+1 that looks much better IMO
+1 too, that looks much better.
The icons/links at the bottom look useful, but "Packages" is cryptic
though — everything is about "packages" in this context.
Zbyszek
8:46 a.m.
On Mon, Jul 10, 2017 at 2:38 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
> <pingou(a)pingoured.fr> wrote:
> > On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> >> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> >> > 3. The default landing page for a package shows a message about
> >> > the missing readme. Maybe we could show the %description there in
> >> > such cases?
> >>
> >> Or as an interim, show the spec file?
> >
> > What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
> >
> > The description comes from the rawhide repo via mdapi. So to update the
> > description, simply update the package in rawhide.
> >
> > You can then simply complement these information with a README file.
>
> +1 that looks much better IMO
+1 too, that looks much better.
The icons/links at the bottom look useful, but "Packages" is cryptic
though — everything is about "packages" in this context.
They map to the same as the ones say here
https://admin.fedoraproject.org/pkgdb/package/rpms/neard/
9:15 a.m.
On Mon, Jul 10, 2017 at 02:46:27PM +0100, Peter Robinson wrote:
On Mon, Jul 10, 2017 at 2:38 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
>> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
>> <pingou(a)pingoured.fr> wrote:
>> > On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>> >> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
>> >> > 3. The default landing page for a package shows a message about
>> >> > the missing readme. Maybe we could show the %description there
in
>> >> > such cases?
>> >>
>> >> Or as an interim, show the spec file?
>> >
>> > What would you think of:
http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>> >
>> > The description comes from the rawhide repo via mdapi. So to update the
>> > description, simply update the package in rawhide.
>> >
>> > You can then simply complement these information with a README file.
>>
>> +1 that looks much better IMO
>
> +1 too, that looks much better.
>
> The icons/links at the bottom look useful, but "Packages" is cryptic
> though — everything is about "packages" in this context.
They map to the same as the ones say here
https://admin.fedoraproject.org/pkgdb/package/rpms/neard/
Right. My point is that the icon description shouldn't just be "packages"
— it should be something which is legible to outside casual contributors.
Maybe "Fedora package administration".
Zbyszek
9:24 a.m.
On Mon, Jul 10, 2017 at 02:15:26PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jul 10, 2017 at 02:46:27PM +0100, Peter Robinson wrote:
> On Mon, Jul 10, 2017 at 2:38 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
> > On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
> >> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
> >> <pingou(a)pingoured.fr> wrote:
> >> > On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> >> >> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew
Jędrzejewski-Szmek wrote:
> >> >> > 3. The default landing page for a package shows a message
about
> >> >> > the missing readme. Maybe we could show the %description
there in
> >> >> > such cases?
> >> >>
> >> >> Or as an interim, show the spec file?
> >> >
> >> > What would you think of:
http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
> >> >
> >> > The description comes from the rawhide repo via mdapi. So to update
the
> >> > description, simply update the package in rawhide.
> >> >
> >> > You can then simply complement these information with a README file.
> >>
> >> +1 that looks much better IMO
> >
> > +1 too, that looks much better.
> >
> > The icons/links at the bottom look useful, but "Packages" is cryptic
> > though — everything is about "packages" in this context.
>
> They map to the same as the ones say here
> https://admin.fedoraproject.org/pkgdb/package/rpms/neard/
Right. My point is that the icon description shouldn't just be "packages"
— it should be something which is legible to outside casual contributors.
Maybe "Fedora package administration".
The `package` app is called `fedora-packages` lives at:
https://apps.fedoraproject.org/packages/
and is meant to be a place for anyone (contributor and non-contributor) to find
information about the packages in Fedora.
It is not an admin interface, you cannot login in there.
I am most definitively open to rename that link, but I lack a better word.
Pierre
11 a.m.
On Mon, Jul 10, 2017 at 04:24:06PM +0200, Pierre-Yves Chibon wrote:
On Mon, Jul 10, 2017 at 02:15:26PM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jul 10, 2017 at 02:46:27PM +0100, Peter Robinson wrote:
> > On Mon, Jul 10, 2017 at 2:38 PM, Zbigniew Jędrzejewski-Szmek
> > <zbyszek(a)in.waw.pl> wrote:
> > > On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
> > >> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
> > >> <pingou(a)pingoured.fr> wrote:
> > >> > On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> > >> >> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew
Jędrzejewski-Szmek wrote:
> > >> >> > 3. The default landing page for a package shows a
message about
> > >> >> > the missing readme. Maybe we could show the
%description there in
> > >> >> > such cases?
> > >> >>
> > >> >> Or as an interim, show the spec file?
> > >> >
> > >> > What would you think of:
http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
> > >> >
> > >> > The description comes from the rawhide repo via mdapi. So to
update the
> > >> > description, simply update the package in rawhide.
> > >> >
> > >> > You can then simply complement these information with a README
file.
> > >>
> > >> +1 that looks much better IMO
> > >
> > > +1 too, that looks much better.
> > >
> > > The icons/links at the bottom look useful, but "Packages" is
cryptic
> > > though — everything is about "packages" in this context.
> >
> > They map to the same as the ones say here
> > https://admin.fedoraproject.org/pkgdb/package/rpms/neard/
>
> Right. My point is that the icon description shouldn't just be
"packages"
> — it should be something which is legible to outside casual contributors.
> Maybe "Fedora package administration".
The `package` app is called `fedora-packages` lives at:
https://apps.fedoraproject.org/packages/
and is meant to be a place for anyone (contributor and non-contributor) to find
information about the packages in Fedora.
It is not an admin interface, you cannot login in there.
Oh, I misunderstood what
Peter wrote.
I am most definitively open to rename that link, but I lack a better
word.
"Fedora package status overview"?
Zbyszek
10:17 a.m.
Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a):
On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>> 3. The default landing page for a package shows a message about
>> the missing readme. Maybe we could show the %description there in
>> such cases?
> Or as an interim, show the spec file?
What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
The description comes from the rawhide repo via mdapi.
Is the mdapi already fixed to provide correct information about
overlapped packages?
https://apps.fedoraproject.org/packages/ruby
I don't think it is based on the link above.
So to update the
description, simply update the package in rawhide.
You can then simply complement these information with a README file.
I think there should be something like "fedpkg generate-readme", where
the generated README could contain badges, which would reference BZ,
Koscheji, Koji, whatever else, it could contain the description etc +
some useful development tips. This would be in similar manner GitHub can
display various badges now. The initial README could be generated during
the repository setup. This way, Pagure won't need any specific
fedora-infrastructure hacks.
Vít
12:31 p.m.
On Mon, Jul 10, 2017 at 05:17:04PM +0200, Vít Ondruch wrote:
Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a):
> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>>> 3. The default landing page for a package shows a message about
>>> the missing readme. Maybe we could show the %description there in
>>> such cases?
>> Or as an interim, show the spec file?
> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>
> The description comes from the rawhide repo via mdapi.
Is the mdapi already fixed to provide correct information about
overlapped packages?
I feel this is a packaging issue.
https://apps.fedoraproject.org/packages/ruby
I don't think it is based on the link above.
What you are pointing out isn't a problem with mdapi but with fedora-packages
and it is caching the info but I also think there is a packaging issue at the
root of this question.
> So to update the
> description, simply update the package in rawhide.
>
> You can then simply complement these information with a README file.
I think there should be something like "fedpkg generate-readme", where
the generated README could contain badges, which would reference BZ,
Koscheji, Koji, whatever else, it could contain the description etc +
some useful development tips. This would be in similar manner GitHub can
display various badges now. The initial README could be generated during
the repository setup. This way, Pagure won't need any specific
fedora-infrastructure hacks.
Pagure already supports some sort of theming allowing to override templates.
This is the mechanism used to display the information above, so this template
isn't part of pagure itself.
Pierre
2:50 a.m.
Dne 10.7.2017 v 19:31 Pierre-Yves Chibon napsal(a):
On Mon, Jul 10, 2017 at 05:17:04PM +0200, Vít Ondruch wrote:
>
> Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a):
>> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>>> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>>>> 3. The default landing page for a package shows a message about
>>>> the missing readme. Maybe we could show the %description there in
>>>> such cases?
>>> Or as an interim, show the spec file?
>> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>>
>> The description comes from the rawhide repo via mdapi.
> Is the mdapi already fixed to provide correct information about
> overlapped packages?
I feel this is a packaging issue.
> https://apps.fedoraproject.org/packages/ruby
>
> I don't think it is based on the link above.
What you are pointing out isn't a problem with mdapi but with fedora-packages
and it is caching the info
Right, I have no idea how it came to conclusion that rubygems is
subpackage of ruby, this is not true, never was true and never will be true.
So lets take a look on mdapi:
https://apps.fedoraproject.org/mdapi/rawhide/pkg/rubygems
What does the 'basename"rub"'means? One could think that this could be
name of the source package, but honestly, I don't know.
https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby
https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby-libs
What is the "co-packages" list? It does not make any sense to me looking
at all three links above.
but I also think there is a packaging issue at the
root of this question.
Overlapping packages is nothing new. And as long as repositories and
depsolver can handle them, there is no problem with them.
Actually it would be pretty natural if one day rubygems is shown as
coming from rubygems SRPM and the other day it would say it comes from
ruby SRPM. This is how DNF works. But mdapi together with packages are
trying to be smarter.
The question is, why there is no trace of "dnf", "libsolv" or
"librepo"
in the source code of mdapi. This is what you should use to get reliable
information about packages.
>> So to update the
>> description, simply update the package in rawhide.
>>
>> You can then simply complement these information with a README file.
> I think there should be something like "fedpkg generate-readme", where
> the generated README could contain badges, which would reference BZ,
> Koscheji, Koji, whatever else, it could contain the description etc +
> some useful development tips. This would be in similar manner GitHub can
> display various badges now. The initial README could be generated during
> the repository setup. This way, Pagure won't need any specific
> fedora-infrastructure hacks.
Pagure already supports some sort of theming allowing to override templates.
This is the mechanism used to display the information above, so this template
isn't part of pagure itself.
But you still need to adjust some templates. I am proposing something
more generic. To adjust the README, you don't need any server side template.
Vít
3:24 a.m.
On 11/07/17 08:50, Vít Ondruch wrote:
Right, I have no idea how it came to conclusion that rubygems is
subpackage of ruby, this is not true, never was true and never will be true.
Err because the spec file says it is? eg on the F26 rpm:
bericote [~] % rpm -qi rubygems | fgrep "Source RPM"
Source RPM : ruby-2.4.1-79.fc26.src.rpm
and, in a dist-git checkout:
bericote [~/ruby] % fgrep %package ruby.spec
%package devel
%package libs
%package -n rubygems
%package -n rubygems-devel
%package -n rubygem-rake
%package irb
%package -n rubygem-rdoc
%package doc
%package -n rubygem-bigdecimal
%package -n rubygem-did_you_mean
%package -n rubygem-io-console
%package -n rubygem-json
%package -n rubygem-minitest
%package -n rubygem-openssl
%package -n rubygem-power_assert
%package -n rubygem-psych
%package -n rubygem-net-telnet
%package -n rubygem-test-unit
%package -n rubygem-xmlrpc
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
4:41 a.m.
Dne 11.7.2017 v 10:24 Tom Hughes napsal(a):
On 11/07/17 08:50, Vít Ondruch wrote:
> Right, I have no idea how it came to conclusion that rubygems is
> subpackage of ruby, this is not true, never was true and never will
> be true.
Err because the spec file says it is? eg on the F26 rpm:
Of course you are right and I meant it the other way around of course.
This is what "packages" app says about it:
~~~
ruby
Subpackage of rubygems <https://apps.fedoraproject.org/packages/rubygems>
~~~
https://apps.fedoraproject.org/packages/ruby
Vít
4:41 a.m.
On Tue, Jul 11, 2017 at 09:50:31AM +0200, Vít Ondruch wrote:
Dne 10.7.2017 v 19:31 Pierre-Yves Chibon napsal(a):
On Mon, Jul 10, 2017 at 05:17:04PM +0200, Vít Ondruch wrote:
Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a):
On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
3. The default landing page for a package shows a message about
the missing readme. Maybe we could show the %description there in
such cases?
Or as an interim, show the spec file?
What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
The description comes from the rawhide repo via mdapi.
Is the mdapi already fixed to provide correct information about
overlapped packages?
I feel this is a packaging issue.
https://apps.fedoraproject.org/packages/ruby
I don't think it is based on the link above.
What you are pointing out isn't a problem with mdapi but with fedora-packages
and it is caching the info
Right, I have no idea how it came to conclusion that rubygems is
subpackage of ruby, this is not true, never was true and never will be
true.
Oh I can easily answer this one:
- Download:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everythi...
- Extract it: bzip2 -d
f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite.bz2
- Open the database: sqlite3
f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite
- Run the query:
SELECT name, arch, version, epoch, release, rpm_sourcerpm FROM packages where name
='rubygems';
Here is the output:
rubygems|noarch|2.6.10|0|100.fc27|rubygems-2.6.10-100.fc27.src.rpm
rubygems|noarch|2.6.11|0|79.fc27|ruby-2.4.1-79.fc27.src.rpm
So in the rpm metadata, there is a rubygems package coming from the ruby source
rpm.
I can't tell you why the metadata think so, but that's what they contain and
thus why mdapi exposes this.
So lets take a look on mdapi:
https://apps.fedoraproject.org/mdapi/rawhide/pkg/rubygems
What does the 'basename "rub"' means? One could think that this
could be
name of the source package, but honestly, I don't know.
I saw this one yesterday, I wonder if this isn't a bug in mdapi eating the last
letter (so a y here).
https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby
https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby-libs
What is the "co-packages" list? It does not make any sense to me looking
at all three links above.
The co-packages are supposed to be the packages generated by the source package.
but I also think there is a packaging issue at the
root of this question.
Overlapping packages is nothing new. And as long as repositories and
depsolver can handle them, there is no problem with them.
Actually it would be pretty natural if one day rubygems is shown as coming
from rubygems SRPM and the other day it would say it comes from ruby SRPM.
This is how DNF works. But mdapi together with packages are trying to be
smarter.
Maybe it would feel natural to you but certainly not to me.
mdapi is not smart, quite the opposite, it exposes what is in the sqlite
databases of the rpm repositories. If it exposes something odd, it is likely
because there is something odd in the databases.
But it is constructed around the idea that there is only one package for a given
name.
The question is, why there is no trace of "dnf",
"libsolv" or "librepo" in
the source code of mdapi. This is what you should use to get reliable
information about packages.
mdapi stands for meta-data API, it is not in any way exposing package
dependencies, it is purely exposing meta data.
So to update the
description, simply update the package in rawhide.
You can then simply complement these information with a README file.
I think there should be something like "fedpkg generate-readme", where
the generated README could contain badges, which would reference BZ,
Koscheji, Koji, whatever else, it could contain the description etc +
some useful development tips. This would be in similar manner GitHub can
display various badges now. The initial README could be generated during
the repository setup. This way, Pagure won't need any specific
fedora-infrastructure hacks.
Pagure already supports some sort of theming allowing to override templates.
This is the mechanism used to display the information above, so this template
isn't part of pagure itself.
But you still need to adjust some templates. I am proposing something more
generic. To adjust the README, you don't need any server side template.
If you feel strongly about this, I'll welcome any help :)
I've done the template, I would be thrilled to not have to maintain it!
Pierre
4:59 a.m.
Dne 11.7.2017 v 11:41 Pierre-Yves Chibon napsal(a):
On Tue, Jul 11, 2017 at 09:50:31AM +0200, Vít Ondruch wrote:
> Dne 10.7.2017 v 19:31 Pierre-Yves Chibon napsal(a):
>
> On Mon, Jul 10, 2017 at 05:17:04PM +0200, Vít Ondruch wrote:
>
>
> Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a):
>
> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>
> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>
> 3. The default landing page for a package shows a message about
> the missing readme. Maybe we could show the %description there in
> such cases?
>
> Or as an interim, show the spec file?
>
> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>
> The description comes from the rawhide repo via mdapi.
>
> Is the mdapi already fixed to provide correct information about
> overlapped packages?
>
> I feel this is a packaging issue.
>
>
> https://apps.fedoraproject.org/packages/ruby
>
> I don't think it is based on the link above.
>
> What you are pointing out isn't a problem with mdapi but with fedora-packages
> and it is caching the info
>
> Right, I have no idea how it came to conclusion that rubygems is
> subpackage of ruby, this is not true, never was true and never will be
> true.
Oh I can easily answer this one:
- Download:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everythi...
- Extract it: bzip2 -d
f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite.bz2
- Open the database: sqlite3
f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite
- Run the query:
SELECT name, arch, version, epoch, release, rpm_sourcerpm FROM packages where name
='rubygems';
Here is the output:
rubygems|noarch|2.6.10|0|100.fc27|rubygems-2.6.10-100.fc27.src.rpm
rubygems|noarch|2.6.11|0|79.fc27|ruby-2.4.1-79.fc27.src.rpm
So in the rpm metadata, there is a rubygems package coming from the ruby source
rpm.
I can't tell you why the metadata think so, but that's what they contain and
thus why mdapi exposes this.
Well, yes. Unfortunately, I said it the other way. But the "packages"
states:
~~~
ruby
Subpackage of rubygems <https://apps.fedoraproject.org/packages/rubygems>
~~~
> So lets take a look on mdapi:
>
> https://apps.fedoraproject.org/mdapi/rawhide/pkg/rubygems
>
> What does the 'basename "rub"' means? One could think that this
could be
> name of the source package, but honestly, I don't know.
I saw this one yesterday, I wonder if this isn't a bug in mdapi eating the last
letter (so a y here).
> https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby
> https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby-libs
>
> What is the "co-packages" list? It does not make any sense to me
looking
> at all three links above.
The co-packages are supposed to be the packages generated by the source package.
But then there are missing quite some packages. I'll borrow the list
from Tom Hughes:
~~~
bericote [~/ruby] % fgrep %package ruby.spec
%package devel
%package libs
%package -n rubygems
%package -n rubygems-devel
%package -n rubygem-rake
%package irb
%package -n rubygem-rdoc
%package doc
%package -n rubygem-bigdecimal
%package -n rubygem-did_you_mean
%package -n rubygem-io-console
%package -n rubygem-json
%package -n rubygem-minitest
%package -n rubygem-openssl
%package -n rubygem-power_assert
%package -n rubygem-psych
%package -n rubygem-net-telnet
%package -n rubygem-test-unit
%package -n rubygem-xmlrpc
~~~
This is 19 packages vs 14 packages listed by mdapi.
> but I also think there is a packaging issue at the
> root of this question.
>
> Overlapping packages is nothing new. And as long as repositories and
> depsolver can handle them, there is no problem with them.
>
> Actually it would be pretty natural if one day rubygems is shown as coming
> from rubygems SRPM and the other day it would say it comes from ruby SRPM.
> This is how DNF works. But mdapi together with packages are trying to be
> smarter.
Maybe it would feel natural to you but certainly not to me.
mdapi is not smart, quite the opposite, it exposes what is in the sqlite
databases of the rpm repositories. If it exposes something odd, it is likely
because there is something odd in the databases.
But it is constructed around the idea that there is only one package for a given
name.
But this is wrong assumption. Repository may contain varaious versions
of package. Look at RHEL repositories. Look at Copr. One package per
name is just Fedoraism and it is due to space constrains AFAIK.
> The question is, why there is no trace of "dnf", "libsolv" or
"librepo" in
> the source code of mdapi. This is what you should use to get reliable
> information about packages.
mdapi stands for meta-data API, it is not in any way exposing package
dependencies, it is purely exposing meta data.
I expect that the metadata will provide the information as my package
manager. If the data differs, then there should be really good reason
for that. I really don't see point why to manage separate routines to
download and parse the metadata when there is available standardized
library.
> So to update the
> description, simply update the package in rawhide.
>
> You can then simply complement these information with a README file.
>
> I think there should be something like "fedpkg generate-readme", where
> the generated README could contain badges, which would reference BZ,
> Koscheji, Koji, whatever else, it could contain the description etc +
> some useful development tips. This would be in similar manner GitHub can
> display various badges now. The initial README could be generated during
> the repository setup. This way, Pagure won't need any specific
> fedora-infrastructure hacks.
>
> Pagure already supports some sort of theming allowing to override templates.
> This is the mechanism used to display the information above, so this template
> isn't part of pagure itself.
>
> But you still need to adjust some templates. I am proposing something more
> generic. To adjust the README, you don't need any server side template.
If you feel strongly about this, I'll welcome any help :)
I've done the template, I would be thrilled to not have to maintain it!
Well .... :)
Vít
5:09 a.m.
* Pierre-Yves Chibon [11/07/2017 11:41] :
But it is constructed around the idea that there is only one package for a given
name.
I'm not sure the assumption is safe to make. A number of perl modules have two
packages (one of them coming from the perl core package, the other from the
package's home on CPAN).
Emmanuel
5:20 a.m.
On Tue, Jul 11, 2017 at 11:09 AM, Emmanuel Seyman <emmanuel(a)seyman.fr> wrote:
* Pierre-Yves Chibon [11/07/2017 11:41] :
>
> But it is constructed around the idea that there is only one package for a given
> name.
I'm not sure the assumption is safe to make. A number of perl modules have two
packages (one of them coming from the perl core package, the other from the
package's home on CPAN).
But there's only one source package in that case, in the core case
they're a sub package of the perl package.
3:49 p.m.
On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > 3. The default landing page for a package shows a message about
> > the missing readme. Maybe we could show the %description there in
> > such cases?
>
> Or as an interim, show the spec file?
What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
The description comes from the rawhide repo via mdapi. So to update the
description, simply update the package in rawhide.
You can then simply complement these information with a README file.
For the curious ones :)
https://src.stg.fedoraproject.org/pagure/rpms/fedocal
Pierre
5:49 p.m.
On Mon, Jul 24, 2017 at 10:49:16PM +0200, Pierre-Yves Chibon wrote:
On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> > On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > 3. The default landing page for a package shows a message about
> > > the missing readme. Maybe we could show the %description there in
> > > such cases?
> >
> > Or as an interim, show the spec file?
>
> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>
> The description comes from the rawhide repo via mdapi. So to update the
> description, simply update the package in rawhide.
>
> You can then simply complement these information with a README file.
For the curious ones :)
https://src.stg.fedoraproject.org/pagure/rpms/fedocal
Nice!
Zbyszek
8:49 p.m.
On Mon, Jul 24, 2017 at 4:49 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> > On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > 3. The default landing page for a package shows a message about
> > > the missing readme. Maybe we could show the %description there in
> > > such cases?
> >
> > Or as an interim, show the spec file?
>
> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>
> The description comes from the rawhide repo via mdapi. So to update the
> description, simply update the package in rawhide.
>
> You can then simply complement these information with a README file.
For the curious ones :)
https://src.stg.fedoraproject.org/pagure/rpms/fedocal
Where's the syntax highlighting? I was hoping we'd have that by now...
--
真実はいつも一つ！/ Always, there's only one truth!
3:38 a.m.
On Mon, Jul 24, 2017 at 09:49:51PM -0400, Neal Gompa wrote:
On Mon, Jul 24, 2017 at 4:49 PM, Pierre-Yves Chibon
<pingou(a)pingoured.fr> wrote:
> On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
>> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>> > On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
>> > > 3. The default landing page for a package shows a message about
>> > > the missing readme. Maybe we could show the %description there in
>> > > such cases?
>> >
>> > Or as an interim, show the spec file?
>>
>> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>>
>> The description comes from the rawhide repo via mdapi. So to update the
>> description, simply update the package in rawhide.
>>
>> You can then simply complement these information with a README file.
>
> For the curious ones :)
> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
>
>
Where's the syntax highlighting? I was hoping we'd have that by now...
Needs an updated package of python-pygments in epel7 (or a compat package).
It hasn't really been a priority for us but that should be something anyone can
take up ;-)
Pierre
7:16 a.m.
On Tue, Jul 25, 2017 at 4:38 AM, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Mon, Jul 24, 2017 at 09:49:51PM -0400, Neal Gompa wrote:
> On Mon, Jul 24, 2017 at 4:49 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr>
wrote:
> > On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
> >> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> >> > On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> >> > > 3. The default landing page for a package shows a message about
> >> > > the missing readme. Maybe we could show the %description there
in
> >> > > such cases?
> >> >
> >> > Or as an interim, show the spec file?
> >>
> >> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png
?
> >>
> >> The description comes from the rawhide repo via mdapi. So to update the
> >> description, simply update the package in rawhide.
> >>
> >> You can then simply complement these information with a README file.
> >
> > For the curious ones :)
> > https://src.stg.fedoraproject.org/pagure/rpms/fedocal
> >
> >
>
> Where's the syntax highlighting? I was hoping we'd have that by now...
Needs an updated package of python-pygments in epel7 (or a compat package).
It hasn't really been a priority for us but that should be something anyone can
take up ;-)
No, you need a special infra package, since pygments is in RHEL 7 already.
--
真実はいつも一つ！/ Always, there's only one truth!
7:45 a.m.
On Tue, Jul 25, 2017 at 08:16:55AM -0400, Neal Gompa wrote:
On Tue, Jul 25, 2017 at 4:38 AM, Pierre-Yves Chibon
<pingou(a)pingoured.fr> wrote:
> On Mon, Jul 24, 2017 at 09:49:51PM -0400, Neal Gompa wrote:
>> On Mon, Jul 24, 2017 at 4:49 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr>
wrote:
>> > On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
>> >> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>> >> > On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew
Jędrzejewski-Szmek wrote:
>> >> > > 3. The default landing page for a package shows a message
about
>> >> > > the missing readme. Maybe we could show the %description
there in
>> >> > > such cases?
>> >> >
>> >> > Or as an interim, show the spec file?
>> >>
>> >> What would you think of:
http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>> >>
>> >> The description comes from the rawhide repo via mdapi. So to update
the
>> >> description, simply update the package in rawhide.
>> >>
>> >> You can then simply complement these information with a README file.
>> >
>> > For the curious ones :)
>> > https://src.stg.fedoraproject.org/pagure/rpms/fedocal
>> >
>> >
>>
>> Where's the syntax highlighting? I was hoping we'd have that by now...
>
> Needs an updated package of python-pygments in epel7 (or a compat package).
> It hasn't really been a priority for us but that should be something anyone can
> take up ;-)
>
No, you need a special infra package, since pygments is in RHEL 7 already.
That's why I spoke of compat package.
Pierre
4:06 p.m.
On Tue, Jul 25, 2017 at 10:38:11AM +0200, Pierre-Yves Chibon wrote:
On Mon, Jul 24, 2017 at 09:49:51PM -0400, Neal Gompa wrote:
> On Mon, Jul 24, 2017 at 4:49 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr>
wrote:
> > On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
> >> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> >> > On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> >> > > 3. The default landing page for a package shows a message about
> >> > > the missing readme. Maybe we could show the %description there
in
> >> > > such cases?
> >> >
> >> > Or as an interim, show the spec file?
> >>
> >> What would you think of:
http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
> >>
> >> The description comes from the rawhide repo via mdapi. So to update the
> >> description, simply update the package in rawhide.
> >>
> >> You can then simply complement these information with a README file.
> >
> > For the curious ones :)
> > https://src.stg.fedoraproject.org/pagure/rpms/fedocal
> >
> >
>
> Where's the syntax highlighting? I was hoping we'd have that by now...
Needs an updated package of python-pygments in epel7 (or a compat package).
It hasn't really been a priority for us but that should be something anyone can
take up ;-)
Thanks to the excellent Igor Gnatenko we know have that package up for review:
https://bugzilla.redhat.com/show_bug.cgi?id=1475536
(it has been tested and it works as desired :))
Pierre
8:50 p.m.
On Wed, Jul 26, 2017 at 5:06 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Tue, Jul 25, 2017 at 10:38:11AM +0200, Pierre-Yves Chibon wrote:
> On Mon, Jul 24, 2017 at 09:49:51PM -0400, Neal Gompa wrote:
> > On Mon, Jul 24, 2017 at 4:49 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr>
wrote:
> > > On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
> > >> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> > >> > On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew
Jędrzejewski-Szmek wrote:
> > >> > > 3. The default landing page for a package shows a message
about
> > >> > > the missing readme. Maybe we could show the %description
there in
> > >> > > such cases?
> > >> >
> > >> > Or as an interim, show the spec file?
> > >>
> > >> What would you think of:
http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
> > >>
> > >> The description comes from the rawhide repo via mdapi. So to update
the
> > >> description, simply update the package in rawhide.
> > >>
> > >> You can then simply complement these information with a README file.
> > >
> > > For the curious ones :)
> > > https://src.stg.fedoraproject.org/pagure/rpms/fedocal
> > >
> > >
> >
> > Where's the syntax highlighting? I was hoping we'd have that by now...
>
> Needs an updated package of python-pygments in epel7 (or a compat package).
> It hasn't really been a priority for us but that should be something anyone can
> take up ;-)
Thanks to the excellent Igor Gnatenko we know have that package up for review:
https://bugzilla.redhat.com/show_bug.cgi?id=1475536
(it has been tested and it works as desired :))
It has also been reviewed and deemed good to go into EPEL. :)
--
真実はいつも一つ！/ Always, there's only one truth!
11:15 a.m.
On Mon, Jul 24, 2017 at 10:49:16PM +0200, Pierre-Yves Chibon wrote:
For the curious ones :)
https://src.stg.fedoraproject.org/pagure/rpms/fedocal
This looks nice. Where does the code for this live? I had the idea that
it could maybe even use status badges that show for example if the all
updates are in stable or if koshei is enabled and the result is
positive. But maybe this is also too much information for that page. I
was wondering, is fedmenu still a thing? Adding this might also make it
easier to get to all the other infra projects.
Kind regards
Till
11:21 a.m.
On Tue, Jul 25, 2017 at 06:15:26PM +0200, Till Maas wrote:
> For the curious ones :)
> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
This looks nice. Where does the code for this live? I had the idea that
it could maybe even use status badges that show for example if the all
updates are in stable or if koshei is enabled and the result is
positive. But maybe this is also too much information for that page. I
was wondering, is fedmenu still a thing? Adding this might also make it
easier to get to all the other infra projects.
Another thing I'd like to see is a link to the upstream -- this is in
pkgdb currently and I find it convenient.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:44 a.m.
On Tue, Jul 25, 2017 at 12:21:36PM -0400, Matthew Miller wrote:
On Tue, Jul 25, 2017 at 06:15:26PM +0200, Till Maas wrote:
> > For the curious ones :)
> > https://src.stg.fedoraproject.org/pagure/rpms/fedocal
>
> This looks nice. Where does the code for this live? I had the idea that
> it could maybe even use status badges that show for example if the all
> updates are in stable or if koshei is enabled and the result is
> positive. But maybe this is also too much information for that page. I
> was wondering, is fedmenu still a thing? Adding this might also make it
> easier to get to all the other infra projects.
Another thing I'd like to see is a link to the upstream -- this is in
pkgdb currently and I find it convenient.
I thought it was in mdapi but doesn't seem to be but it seems to be in the
repodata so easy enough to add it :)
Pierre
11:21 a.m.
On Tue, Jul 25, 2017 at 06:15:26PM +0200, Till Maas wrote:
On Mon, Jul 24, 2017 at 10:49:16PM +0200, Pierre-Yves Chibon wrote:
> For the curious ones :)
> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
This looks nice. Where does the code for this live? I had the idea that
it could maybe even use status badges that show for example if the all
updates are in stable or if koshei is enabled and the result is
positive. But maybe this is also too much information for that page.
The code lives in pagure-dist-git on pagure.io, we're basically overriding the
default repo_info template from pagure to use our custom one.
I was wondering, is fedmenu still a thing? Adding this might also
make it
easier to get to all the other infra projects.
You're right we should add fedmenu.
Pierre
12:20 p.m.
Dne 24.7.2017 v 22:49 Pierre-Yves Chibon napsal(a):
On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>>> 3. The default landing page for a package shows a message about
>>> the missing readme. Maybe we could show the %description there in
>>> such cases?
>> Or as an interim, show the spec file?
> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>
> The description comes from the rawhide repo via mdapi. So to update the
> description, simply update the package in rawhide.
>
> You can then simply complement these information with a README file.
For the curious ones :)
https://src.stg.fedoraproject.org/pagure/rpms/fedocal
Will there be something replacing
https://admin.fedoraproject.org/pkgdb/packager/vondruch/
?
Vít
12:41 p.m.
On Wed, Jul 26, 2017 at 07:20:38PM +0200, Vít Ondruch wrote:
Dne 24.7.2017 v 22:49 Pierre-Yves Chibon napsal(a):
> On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
>> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>>> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
>>>> 3. The default landing page for a package shows a message about
>>>> the missing readme. Maybe we could show the %description there in
>>>> such cases?
>>> Or as an interim, show the spec file?
>> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>>
>> The description comes from the rawhide repo via mdapi. So to update the
>> description, simply update the package in rawhide.
>>
>> You can then simply complement these information with a README file.
> For the curious ones :)
> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
Will there be something replacing
https://admin.fedoraproject.org/pkgdb/packager/vondruch/
https://src.stg.fedoraproject.org/pagure/user/vondruch
This is likely the closest thing to it.
Pierre
12:49 p.m.
On Wed, Jul 26, 2017 at 1:41 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Wed, Jul 26, 2017 at 07:20:38PM +0200, Vít Ondruch wrote:
>
>
> Dne 24.7.2017 v 22:49 Pierre-Yves Chibon napsal(a):
> > On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
> >> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> >>> On Fri, Jul 07, 2017 at 03:05:43AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> >>>> 3. The default landing page for a package shows a message about
> >>>> the missing readme. Maybe we could show the %description there
in
> >>>> such cases?
> >>> Or as an interim, show the spec file?
> >> What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png
?
> >>
> >> The description comes from the rawhide repo via mdapi. So to update the
> >> description, simply update the package in rawhide.
> >>
> >> You can then simply complement these information with a README file.
> > For the curious ones :)
> > https://src.stg.fedoraproject.org/pagure/rpms/fedocal
>
> Will there be something replacing
>
> https://admin.fedoraproject.org/pkgdb/packager/vondruch/
https://src.stg.fedoraproject.org/pagure/user/vondruch
This is likely the closest thing to it.
Can't we have a nice simple list like what pkgdb offers as a separate
thing? The pagure listing is kinda huge and obnoxious, and the pkgdb
listing is nice and concise, great for linking to in resumes or social
networks. :)
--
真実はいつも一つ！/ Always, there's only one truth!
12:35 a.m.
Dne 26.7.2017 v 19:41 Pierre-Yves Chibon napsal(a):
On Wed, Jul 26, 2017 at 07:20:38PM +0200, Vít Ondruch wrote:
>
> Dne 24.7.2017 v 22:49 Pierre-Yves Chibon napsal(a):
>> On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
>> For the curious ones :)
>> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
> Will there be something replacing
>
> https://admin.fedoraproject.org/pkgdb/packager/vondruch/
https://src.stg.fedoraproject.org/pagure/user/vondruch
This is likely the closest thing to it.
Thx
Now I noticed several things:
1) The graph of my user page shows no activity. Is it just staging
issue? Is it data import issue? Will it work on production?
2) The "contributors" list does not appear to be correct. Looking at
"ruby", there is listed "tagoh" user, who is in pkgdb
"Obsolete" on all
branches. Is it old data on staging? Not sure when he was obsoleted in
pkgdb ....
3) How are the "groups" handled? Looking at "rubygem-puma", there is
not
the "group::ruby-packagers-sig" listed (might be old data, since neither
I am listed). But trying to lookup nodejs or npm, which are owned by
"group::nodejs-sig", these two are not available at all. Tried several
others from top of the list of packages of this group, non appears to be
available in pagure (?!?).
Vít
3:05 a.m.
On Thu, Jul 27, 2017 at 07:35:46AM +0200, Vít Ondruch wrote:
Dne 26.7.2017 v 19:41 Pierre-Yves Chibon napsal(a):
> On Wed, Jul 26, 2017 at 07:20:38PM +0200, Vít Ondruch wrote:
>>
>> Dne 24.7.2017 v 22:49 Pierre-Yves Chibon napsal(a):
>>> On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
>>> For the curious ones :)
>>> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
>> Will there be something replacing
>>
>> https://admin.fedoraproject.org/pkgdb/packager/vondruch/
> https://src.stg.fedoraproject.org/pagure/user/vondruch
>
> This is likely the closest thing to it.
>
Thx
Now I noticed several things:
1) The graph of my user page shows no activity. Is it just staging
issue? Is it data import issue? Will it work on production?
The activity log hasn't been filled, we could try doing it but that will take a
really long time as it would have to run through each commits in all the repos.
However, new activity should show up just fine.
2) The "contributors" list does not appear to be correct.
Looking at
"ruby", there is listed "tagoh" user, who is in pkgdb
"Obsolete" on all
branches. Is it old data on staging? Not sure when he was obsoleted in
pkgdb ....
The timeline shows he was obsoleted in December 2016, the data in pagure is from
yesterday (I keep running the script to add/test more things), so I think you
found a bug in this script.
I'll dig into this, thanks!
3) How are the "groups" handled? Looking at
"rubygem-puma", there is not
the "group::ruby-packagers-sig" listed (might be old data, since neither
I am listed). But trying to lookup nodejs or npm, which are owned by
"group::nodejs-sig", these two are not available at all. Tried several
others from top of the list of packages of this group, non appears to be
available in pagure (?!?).
This is odd, thanks for noticing.
Pierre
3:29 a.m.
On Thu, Jul 27, 2017 at 10:05:40AM +0200, Pierre-Yves Chibon wrote:
On Thu, Jul 27, 2017 at 07:35:46AM +0200, Vít Ondruch wrote:
>
>
> Dne 26.7.2017 v 19:41 Pierre-Yves Chibon napsal(a):
> > On Wed, Jul 26, 2017 at 07:20:38PM +0200, Vít Ondruch wrote:
> >>
> >> Dne 24.7.2017 v 22:49 Pierre-Yves Chibon napsal(a):
> >>> On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
> >>> For the curious ones :)
> >>> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
> >> Will there be something replacing
> >>
> >> https://admin.fedoraproject.org/pkgdb/packager/vondruch/
> > https://src.stg.fedoraproject.org/pagure/user/vondruch
> >
> > This is likely the closest thing to it.
> >
>
> Thx
>
> Now I noticed several things:
>
> 1) The graph of my user page shows no activity. Is it just staging
> issue? Is it data import issue? Will it work on production?
The activity log hasn't been filled, we could try doing it but that will take a
really long time as it would have to run through each commits in all the repos.
However, new activity should show up just fine.
> 2) The "contributors" list does not appear to be correct. Looking at
> "ruby", there is listed "tagoh" user, who is in pkgdb
"Obsolete" on all
> branches. Is it old data on staging? Not sure when he was obsoleted in
> pkgdb ....
The timeline shows he was obsoleted in December 2016, the data in pagure is from
yesterday (I keep running the script to add/test more things), so I think you
found a bug in this script.
I'll dig into this, thanks!
> 3) How are the "groups" handled? Looking at "rubygem-puma",
there is not
> the "group::ruby-packagers-sig" listed (might be old data, since neither
> I am listed). But trying to lookup nodejs or npm, which are owned by
> "group::nodejs-sig", these two are not available at all. Tried several
> others from top of the list of packages of this group, non appears to be
> available in pagure (?!?).
This is odd, thanks for noticing.
Phew, found it, the script is running against the staging instance of pkgdb
(obviously since staging cannot talk to production) and the staging instance of
pkgdb clearly has some old data.
I will look into updating the pkgdb DB in stg and re-run the script so we have a
more up to date picture.
Pierre
3:38 a.m.
Dne 27.7.2017 v 10:29 Pierre-Yves Chibon napsal(a):
On Thu, Jul 27, 2017 at 10:05:40AM +0200, Pierre-Yves Chibon wrote:
> On Thu, Jul 27, 2017 at 07:35:46AM +0200, Vít Ondruch wrote:
>>
>> Dne 26.7.2017 v 19:41 Pierre-Yves Chibon napsal(a):
>>> On Wed, Jul 26, 2017 at 07:20:38PM +0200, Vít Ondruch wrote:
>>>> Dne 24.7.2017 v 22:49 Pierre-Yves Chibon napsal(a):
>>>>> On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
>>>>> For the curious ones :)
>>>>> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
>>>> Will there be something replacing
>>>>
>>>> https://admin.fedoraproject.org/pkgdb/packager/vondruch/
>>> https://src.stg.fedoraproject.org/pagure/user/vondruch
>>>
>>> This is likely the closest thing to it.
>>>
>> Thx
>>
>> Now I noticed several things:
>>
>> 1) The graph of my user page shows no activity. Is it just staging
>> issue? Is it data import issue? Will it work on production?
> The activity log hasn't been filled, we could try doing it but that will take a
> really long time as it would have to run through each commits in all the repos.
> However, new activity should show up just fine.
>
>> 2) The "contributors" list does not appear to be correct. Looking at
>> "ruby", there is listed "tagoh" user, who is in pkgdb
"Obsolete" on all
>> branches. Is it old data on staging? Not sure when he was obsoleted in
>> pkgdb ....
> The timeline shows he was obsoleted in December 2016, the data in pagure is from
> yesterday (I keep running the script to add/test more things), so I think you
> found a bug in this script.
> I'll dig into this, thanks!
>
>> 3) How are the "groups" handled? Looking at "rubygem-puma",
there is not
>> the "group::ruby-packagers-sig" listed (might be old data, since
neither
>> I am listed). But trying to lookup nodejs or npm, which are owned by
>> "group::nodejs-sig", these two are not available at all. Tried several
>> others from top of the list of packages of this group, non appears to be
>> available in pagure (?!?).
> This is odd, thanks for noticing.
Phew, found it, the script is running against the staging instance of pkgdb
(obviously since staging cannot talk to production) and the staging instance of
pkgdb clearly has some old data.
Makes sense.
I will look into updating the pkgdb DB in stg and re-run the script so we have a
more up to date picture.
Thx!
V.
3:36 a.m.
Dne 27.7.2017 v 10:05 Pierre-Yves Chibon napsal(a):
On Thu, Jul 27, 2017 at 07:35:46AM +0200, Vít Ondruch wrote:
>
> Dne 26.7.2017 v 19:41 Pierre-Yves Chibon napsal(a):
>> On Wed, Jul 26, 2017 at 07:20:38PM +0200, Vít Ondruch wrote:
>>> Dne 24.7.2017 v 22:49 Pierre-Yves Chibon napsal(a):
>>>> On Mon, Jul 10, 2017 at 11:23:35AM +0200, Pierre-Yves Chibon wrote:
>>>> For the curious ones :)
>>>> https://src.stg.fedoraproject.org/pagure/rpms/fedocal
>>> Will there be something replacing
>>>
>>> https://admin.fedoraproject.org/pkgdb/packager/vondruch/
>> https://src.stg.fedoraproject.org/pagure/user/vondruch
>>
>> This is likely the closest thing to it.
>>
> Thx
>
> Now I noticed several things:
>
> 1) The graph of my user page shows no activity. Is it just staging
> issue? Is it data import issue? Will it work on production?
The activity log hasn't been filled, we could try doing it but that will take a
really long time as it would have to run through each commits in all the repos.
However, new activity should show up just fine.
New activity is probably enough.
> 2) The "contributors" list does not appear to be correct. Looking at
> "ruby", there is listed "tagoh" user, who is in pkgdb
"Obsolete" on all
> branches. Is it old data on staging? Not sure when he was obsoleted in
> pkgdb ....
The timeline shows he was obsoleted in December 2016,
Ah, I knew the information must be visible somewhere. This leads me to
question is similar information accessible in pagure somewhere? ;)
But anyway, I was not sure about the age of the data in staging, since
for example the ruby repo says it was "created 19h ago" and the "recent
commit in master committed 8 months ago". This does not corresponds with
the official dist-git (actually neither the repo age nor the recent commit).
Looking at f26 branch [1], the last commit is from 12 years ago? The
branch was created around 1st of March, so what is the content?
[1] https://src.stg.fedoraproject.org/pagure/rpms/ruby/commits/f26
the data in pagure is from
yesterday (I keep running the script to add/test more things), so I think you
found a bug in this script.
I'll dig into this, thanks!
> 3) How are the "groups" handled? Looking at "rubygem-puma", there
is not
> the "group::ruby-packagers-sig" listed (might be old data, since neither
> I am listed). But trying to lookup nodejs or npm, which are owned by
> "group::nodejs-sig", these two are not available at all. Tried several
> others from top of the list of packages of this group, non appears to be
> available in pagure (?!?).
This is odd, thanks for noticing.
YAW
V.
3:50 a.m.
On Thu, Jul 27, 2017 at 10:36:29AM +0200, Vít Ondruch wrote:
Dne 27.7.2017 v 10:05 Pierre-Yves Chibon napsal(a):
>> 2) The "contributors" list does not appear to be correct. Looking at
>> "ruby", there is listed "tagoh" user, who is in pkgdb
"Obsolete" on all
>> branches. Is it old data on staging? Not sure when he was obsoleted in
>> pkgdb ....
> The timeline shows he was obsoleted in December 2016,
Ah, I knew the information must be visible somewhere. This leads me to
question is similar information accessible in pagure somewhere? ;)
But anyway, I was not sure about the age of the data in staging, since
for example the ruby repo says it was "created 19h ago" and the "recent
commit in master committed 8 months ago". This does not corresponds with
the official dist-git (actually neither the repo age nor the recent commit).
This make sense, the date created is the date of the creation of the project on
pagure so independent from the git repo history.
Looking at f26 branch [1], the last commit is from 12 years ago? The
branch was created around 1st of March, so what is the content?
The content of the git repo is probably an old snapshot of prod. I honestly
don't remember when we last sync ited, I'm less worried about this part as pagure
doesn't touch it, while about the sync from pkgdb is new.
Pkgdb in stg is now in sync with prod, let's reload the data in pagure :)
Pierre
3:11 a.m.
On Thu, Jul 27, 2017 at 10:50:13AM +0200, Pierre-Yves Chibon wrote:
On Thu, Jul 27, 2017 at 10:36:29AM +0200, Vít Ondruch wrote:
> Dne 27.7.2017 v 10:05 Pierre-Yves Chibon napsal(a):
> >> 2) The "contributors" list does not appear to be correct. Looking
at
> >> "ruby", there is listed "tagoh" user, who is in pkgdb
"Obsolete" on all
> >> branches. Is it old data on staging? Not sure when he was obsoleted in
> >> pkgdb ....
> > The timeline shows he was obsoleted in December 2016,
>
> Ah, I knew the information must be visible somewhere. This leads me to
> question is similar information accessible in pagure somewhere? ;)
>
> But anyway, I was not sure about the age of the data in staging, since
> for example the ruby repo says it was "created 19h ago" and the
"recent
> commit in master committed 8 months ago". This does not corresponds with
> the official dist-git (actually neither the repo age nor the recent commit).
This make sense, the date created is the date of the creation of the project on
pagure so independent from the git repo history.
> Looking at f26 branch [1], the last commit is from 12 years ago? The
> branch was created around 1st of March, so what is the content?
The content of the git repo is probably an old snapshot of prod. I honestly
don't remember when we last sync ited, I'm less worried about this part as
pagure
doesn't touch it, while about the sync from pkgdb is new.
Pkgdb in stg is now in sync with prod, let's reload the data in pagure :)
Ok so in addition to the source of data being out-dated I ran into a bug in
pkgdb2 yesterday that was returning invalid data in a specific case. I managed
to go around this bug and re-sync everything to pagure in stg.
This is how it looks now:
https://src.stg.fedoraproject.org/pagure/rpms/ruby
https://src.stg.fedoraproject.org/pagure/rpms/rubygem-puma
As far as I can see this is looking all good but you know the more eyes the
better :)
Thanks for finding this out!
Pierre
4:01 a.m.
Dne 28.7.2017 v 10:11 Pierre-Yves Chibon napsal(a):
As far as I can see this is looking all good but you know the more eyes the
better :)
https://src.stg.fedoraproject.org/pagure/group/ruby-packagers-sig
releng is ruby-packagers-sig group member? How so?
https://admin.fedoraproject.org/accounts/group/view/ruby-packagers-sig
Thanks for finding this out!
Thank you for polishing this out :)
Vít
5:14 a.m.
On Fri, Jul 28, 2017 at 11:01:35AM +0200, Vít Ondruch wrote:
Dne 28.7.2017 v 10:11 Pierre-Yves Chibon napsal(a):
>
> As far as I can see this is looking all good but you know the more eyes the
> better :)
https://src.stg.fedoraproject.org/pagure/group/ruby-packagers-sig
releng is ruby-packagers-sig group member? How so?
releng is the bot account used by releng for things like mass-rebuild.
In this case I needed an account to create the group and since the group creator
cannot be removed from the group, I used releng. So it is present in all groups
and is the one creating them on the pagure side.
Pierre
9:31 a.m.
On Thu, Jul 27, 2017 at 10:05:40AM +0200, Pierre-Yves Chibon wrote:
The activity log hasn't been filled, we could try doing it but
that
will take a really long time as it would have to run through each
commits in all the repos. However, new activity should show up just
fine.
This is not urgent but if it could be put on the list to do sometime,
I think it's valuable.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:39 p.m.
IMHO, based on first impressions, new features aside. I don't like the interface
responsiveness.
If I compare it with cgit, cgit is reasonably fast with an nice overview. Browsing pages
with packages with pagure is slower, browsing users pages is unusable, it literally takes
minutes to load a page for me. Yeah, it maybe can be fixed with cache but that leads to
another sets of problems like making sure page always serves fresh and accurate content.
Makes me wonder, why newer software needs to be so slow...
1:43 p.m.
On Sat, Jul 08, 2017 at 05:39:49PM -0000, Samuel Rakitničan wrote:
IMHO, based on first impressions, new features aside. I don't
like the interface responsiveness.
If I compare it with cgit, cgit is reasonably fast with an nice overview. Browsing pages
with packages with pagure is slower, browsing users pages is unusable, it literally takes
minutes to load a page for me. Yeah, it maybe can be fixed with cache but that leads to
another sets of problems like making sure page always serves fresh and accurate content.
Nah, most likely stg.fp.o is just some rpi on somebody's desk or a vm
stuck in the corner of the infrastructure. I don't think you can make
any conjectures about performance or reliability based on the staging
instance.
Zbyszek
9:49 a.m.
Dne 8.7.2017 v 20:43 Zbigniew Jędrzejewski-Szmek napsal(a):
Nah, most likely stg.fp.o is just some rpi on somebody's desk or
a vm
stuck in the corner of the infrastructure. I don't think you can make
any conjectures about performance or reliability based on the staging
instance.
Nope. AFAIK Stg machines are real machines in proper infrastructure. They may be slow by
few percent, but moving to prod
will not make it much faster. So if anything is slow in STG then it is valid issue.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
10:02 a.m.
On Mon, Jul 10, 2017 at 04:49:32PM +0200, Miroslav Suchý wrote:
Dne 8.7.2017 v 20:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> Nah, most likely stg.fp.o is just some rpi on somebody's desk or a vm
> stuck in the corner of the infrastructure. I don't think you can make
> any conjectures about performance or reliability based on the staging
> instance.
Nope. AFAIK Stg machines are real machines in proper infrastructure. They may be slow by
few percent, but moving to prod
will not make it much faster. So if anything is slow in STG then it is valid issue.
They are real machines but may have less memory or cpus than prod ones. So it is
at this stage a little hard to figure how better or worse it will be in prod.
Pierre
11:02 a.m.
On Mon, Jul 10, 2017 at 05:02:25PM +0200, Pierre-Yves Chibon wrote:
On Mon, Jul 10, 2017 at 04:49:32PM +0200, Miroslav Suchý wrote:
> Dne 8.7.2017 v 20:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > Nah, most likely stg.fp.o is just some rpi on somebody's desk or a vm
> > stuck in the corner of the infrastructure. I don't think you can make
> > any conjectures about performance or reliability based on the staging
> > instance.
>
> Nope. AFAIK Stg machines are real machines in proper infrastructure. They may be
slow by few percent, but moving to prod
> will not make it much faster. So if anything is slow in STG then it is valid issue.
They are real machines but may have less memory or cpus than prod ones. So it is
at this stage a little hard to figure how better or worse it will be in prod.
Although also fair to point out there've been numerous performance
improvements thus far, and no reason to think there won't be more.
Pagure is eminently hackable so we are still encouraging contribution
upstream (of which there has been a lot already).
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
2462
days inactive
2484
days old
51 comments
13 participants
participants (13)
-
Emmanuel Seyman -
Jason L Tibbitts III -
Matthew Miller -
Miroslav Suchý -
Neal Gompa -
Paul W. Frields -
Peter Robinson -
Pierre-Yves Chibon -
Samuel Rakitničan -
Till Maas -
Tom Hughes -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek