Re: Git Forge Requirements: Please see the Community Blog

[Nicolas Mailhot via devel]

Le mardi 21 janvier 2020 à 16:34 +, Leigh Griffin a écrit :

Hi,

> On behalf of the CPE team I want to draw the communities attention to
> a recent blog post which you may be impacted by:
>  https://communityblog.fedoraproject.org/git-forge-requirements/

Requirements:

1. the url to the archive (tar.xz, tar.bz2, etc) corresponding to
various code states (commit/tag/release/fork…) should be regular and
stable (ideally, identical to the current ones to avoid redoing all the
automation that plugs in pagure today, redoing source declaration in
specs, etc)

2. the git repos should be fully accessible over https (read and write)
to allow the contributionsfrom environments where ssh is filtered for
security reasons. It’s hard enough to nurture the contributor pool
whithout infra that can not work with nowaday’s most common access
protocol (contributors should do xxx means no contributors given the
current project attractivity deficit)

Regards

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Pierre-Yves Chibon]

On Tue, Jan 28, 2020 at 11:51:29PM +0100, Dan Čermák wrote:
> "Richard W.M. Jones"  writes:
> 
> > I always think that Fedora works fine if you maintain 1-5 packages.
> > It's possible to maintain 20 with a lot of work.  And if you want to
> > maintain 100+ (things like the ocaml-* set that I help to maintain)
> > then you have to write your own automation.  Could we do things
> > better?  No one asked for them, but here are my ideas ...
> >
> > ---
> >
> > * kill the %changelog
> >
> > Please, let's kill it, and generate it from the git changelog.
> > I'm glad to see there's a proposal to do this.
> >
> > A general principle I'm following here is a packager should never
> > be asked to enter the same information twice.
> >
> > * committing to git should build the package
> >
> > Is there a reason why this wouldn't be the case?
> 
> Not really no. I've been involved quite a bit in building packages on
> openSUSE's Buildservice and every commit there results in a rebuild. So it
> is doable, *but* OBS has the advantage that it discards all builds
> except for the most recent successful one, or it would have run out of
> storage ages ago.
> 
> Although someone (Randy Barlow maybe?) had the idea to generate the
> changelog and to trigger builds from git tags instead of commits, which
> has a certain charm to it as well. If there was a choice whether to
> trigger builds from commits or tags and how to generate the %changelog,
> then I think that most use cases should be covered?

The original idea of using git tag is Jeremy Cline's.
If we support: automatically building from commit or not, then I don't think we
need to support building from git tag, using the current approach would work
just as well when you don't want to build from commit.

> > * commit groups of packages together
> >
> > One reason why automatic commit -> build might not be desirable is if
> > you're trying to build a group of packages in a side tag.  In my
> > opinion this means we should allow groups of packages to be committed
> > together.  (Unfortunately because we chose to put every package in its
> > own git repo, the obvious way to do this can't work, but we could
> > still have a "ChangeId:" header in the commit message that ties
> > packages together).
> >
> > The packages should be built in build dependency order into a side
> > tag, and the side tag turned into an update, with no further
> > involvement from the packager unless something fails to build.
> >
> > This change on its own would solve the main problem that
> > affects people maintaining large sets of packages.
> 
> How about something like `fedpkg add-to-side-tag` (yes the name needs
> work) that would work like this:
> 
> $ fedpkg request-side-tag
> $ fedpkg add-to-side-tag $tag_name $pkgA $pkgB $pkgC $pkgGlob
> 
> Now all git commits/tags pushed to $pkgA $pkgB $pkgC $pkgGlob result in
> them being built in the side tag $tag_name by default. Once the side tag
> is merged, you go back to building the "ordinary way".

Isn't that just fedpkg chain-build --target=$tag_name ... ?
This is already existing and working, however, it requires the different
packages are up to date in git (ie: you've made and push the commit updating the
spec file to the next release/version) which goes against the point above about
automatically build on commit.


Pierre


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Richard W.M. Jones]

On Tue, Jan 28, 2020 at 04:10:17PM -0500, Robbie Harwood wrote:
> Stephen John Smoogen  writes:
> 
> > On Tue, 28 Jan 2020 at 13:01, Robbie Harwood  wrote:
> >>
> >> "Richard W.M. Jones"  writes:
> >>
> >> > I always think that Fedora works fine if you maintain 1-5 packages.
> >> > It's possible to maintain 20 with a lot of work.  And if you want to
> >> > maintain 100+ (things like the ocaml-* set that I help to maintain)
> >> > then you have to write your own automation.  Could we do things
> >> > better?  No one asked for them, but here are my ideas ...
> >> >
> >> > ---
> >> >
> >> > * CVE bugs should autoclose when a package is rebased
> >> >
> >> > Fabiano built the mingw-openssl package recently, but there are still
> >> > a load of open CVE bugs against this package referring to the older
> >> > version.  These should be closed automatically.  I think this will
> >> > require collecting the version of the package that fixes a CVE and
> >> > recording that in Bugzilla (or in the package itself in some standard
> >> > way).
> >>
> >> This is an interesting idea, and I appreciate you're considering ways to
> >> resolve this problem.  However, I'm concerned that this will lead to
> >> maintainers not actually checking whether a version fixes an issue -
> >> since we don't have automatic verification (or even usually manual
> >> verification) of security fixes, that wouldn't get caught.
> >>
> >
> > You are assuming that maintainers actually check to see if a version
> > fixes an issue already. If a packager has 100's or 1000's of
> > packages.. there is no way they will have done so except on a 1 in a
> > million case set. I think if are going to aim that a packager can
> > 'maintain' hundreds or thousands of packages that we also assume that
> > this security is not going to be checked by the maintainer. If it
> > needs to be checked it will need to be 'outsourced' to some group who
> > can do so.
> 
> Per Package Maintainer Responsibilities [1], maintainers are expected to
> "deal with reported bugs in a timely manner" and reach out if they
> cannot handle the load.  I think it's reasonable to expect maintainers
> to be close to compliance with the policy they agreed to when becoming
> maintainers :)
> 
> Personally, I think if you have enough packages that you cannot actually
> triage your own bugtracker, you have too many packages.  I don't think
> it's at all reasonable for one person to be responsible for "100's or
> 1000s of packages", and I think not knowing whether security issues are
> or are not fixed in a given version of them is a perfect illustration of
> why that doesn't work.
> 
> What I would like us to do is move away from needing to do that.
> Whether that involves more SIG-like maintainer groups, or a different
> format, I don't know; but one thing we do need is more monitoring of the
> security issues than we have right now.

I fundamentally disagree.  These things are entirely possible if there
is more automation, and I've shown how I think it could be done.  AND
we need to do this too, increasing packager productivity is the number 1
issue with Fedora packaging and has knock-on benefits everywhere.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Richard W.M. Jones]

On Tue, Jan 28, 2020 at 02:06:40PM -0500, Stephen John Smoogen wrote:
> My main concern is that we have been coming up with 'standard'
> proposals for 20 years and we can't seem to get more than any 4
> maintainers to agree to what that means... even if they do the same
> work in Debian/SuSE/Arch etc. Too many idiosyncratic techniques which
> they use to keep themselves sane or working in whatever environments
> they have.
> 
> At this point, I will take whatever we can standardize on even if it
> is clay tablets mailed to Babylon (ok maybe something a little less
> archaic)

Likely we can get the GNU project involved here.

A simple "METADATA" file in the top level of each project
containing the information we need in a format to be decided.

If you think about it, we cannot even get the *name or version* of a
project mechanically at the moment, which is incredible really.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Richard W.M. Jones]

On Tue, Jan 28, 2020 at 11:51:29PM +0100, Dan Čermák wrote:
> "Richard W.M. Jones"  writes:
> > * CVE bugs should autoclose when a package is rebased
> 
> I don't think this is a good idea as you should actually check that this
> update fixes the CVE.

If we collect the data that version X fixes CVE Y, then
the bug can be closed automatically when version >= X
is built, and it's entirely as safe as today.  We don't
tell packagers they must try to actively exploit their
new build to ensure the exploit has been fixed (at least
I hope we don't ...)

Collecting that data should be possible.  I have suggested that
we work with GNU and other Linux distros to start encouraging
upstreams to provide this data mechanically.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Daniel P . Berrangé]

On Wed, Jan 29, 2020 at 09:26:43AM +, Richard W.M. Jones wrote:
> On Tue, Jan 28, 2020 at 02:06:40PM -0500, Stephen John Smoogen wrote:
> > My main concern is that we have been coming up with 'standard'
> > proposals for 20 years and we can't seem to get more than any 4
> > maintainers to agree to what that means... even if they do the same
> > work in Debian/SuSE/Arch etc. Too many idiosyncratic techniques which
> > they use to keep themselves sane or working in whatever environments
> > they have.
> > 
> > At this point, I will take whatever we can standardize on even if it
> > is clay tablets mailed to Babylon (ok maybe something a little less
> > archaic)
> 
> Likely we can get the GNU project involved here.
> 
> A simple "METADATA" file in the top level of each project
> containing the information we need in a format to be decided.
> 
> If you think about it, we cannot even get the *name or version* of a
> project mechanically at the moment, which is incredible really.

AppStream metadata is probably the best upstream adopted metadata
system that exists right now:

  https://www.freedesktop.org/software/appstream/docs/

It has wide adoption amongst desktop applications, since it is used to
populate the software install tools used by various desktop environments,
but it isn't restricted to just desktop apps.

One caveat is that often the metadata file shipped in the tarball
is not complete & is expanded by the build system.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Richard W.M. Jones]

On Wed, Jan 29, 2020 at 10:04:32AM +0100, Pierre-Yves Chibon wrote:
> On Tue, Jan 28, 2020 at 11:51:29PM +0100, Dan Čermák wrote:
> > "Richard W.M. Jones"  writes:
> > 
> > > I always think that Fedora works fine if you maintain 1-5 packages.
> > > It's possible to maintain 20 with a lot of work.  And if you want to
> > > maintain 100+ (things like the ocaml-* set that I help to maintain)
> > > then you have to write your own automation.  Could we do things
> > > better?  No one asked for them, but here are my ideas ...
> > >
> > > ---
> > >
> > > * kill the %changelog
> > >
> > > Please, let's kill it, and generate it from the git changelog.
> > > I'm glad to see there's a proposal to do this.
> > >
> > > A general principle I'm following here is a packager should never
> > > be asked to enter the same information twice.
> > >
> > > * committing to git should build the package
> > >
> > > Is there a reason why this wouldn't be the case?
> > 
> > Not really no. I've been involved quite a bit in building packages on
> > openSUSE's Buildservice and every commit there results in a rebuild. So it
> > is doable, *but* OBS has the advantage that it discards all builds
> > except for the most recent successful one, or it would have run out of
> > storage ages ago.
> > 
> > Although someone (Randy Barlow maybe?) had the idea to generate the
> > changelog and to trigger builds from git tags instead of commits, which
> > has a certain charm to it as well. If there was a choice whether to
> > trigger builds from commits or tags and how to generate the %changelog,
> > then I think that most use cases should be covered?
> 
> The original idea of using git tag is Jeremy Cline's.
> If we support: automatically building from commit or not, then I don't think 
> we
> need to support building from git tag, using the current approach would work
> just as well when you don't want to build from commit.
> 
> > > * commit groups of packages together
> > >
> > > One reason why automatic commit -> build might not be desirable is if
> > > you're trying to build a group of packages in a side tag.  In my
> > > opinion this means we should allow groups of packages to be committed
> > > together.  (Unfortunately because we chose to put every package in its
> > > own git repo, the obvious way to do this can't work, but we could
> > > still have a "ChangeId:" header in the commit message that ties
> > > packages together).
> > >
> > > The packages should be built in build dependency order into a side
> > > tag, and the side tag turned into an update, with no further
> > > involvement from the packager unless something fails to build.
> > >
> > > This change on its own would solve the main problem that
> > > affects people maintaining large sets of packages.
> > 
> > How about something like `fedpkg add-to-side-tag` (yes the name needs
> > work) that would work like this:
> > 
> > $ fedpkg request-side-tag
> > $ fedpkg add-to-side-tag $tag_name $pkgA $pkgB $pkgC $pkgGlob
> > 
> > Now all git commits/tags pushed to $pkgA $pkgB $pkgC $pkgGlob result in
> > them being built in the side tag $tag_name by default. Once the side tag
> > is merged, you go back to building the "ordinary way".
> 
> Isn't that just fedpkg chain-build --target=$tag_name ... ?
> This is already existing and working, however, it requires the different
> packages are up to date in git (ie: you've made and push the commit updating 
> the
> spec file to the next release/version) which goes against the point above 
> about
> automatically build on commit.

Needs to be something which builds in BuildRequire order to solve the
actual problem.  Also AIUI fedpkg chain-build doesn't work except in
Rawhide, although I'm not sure why that is?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Andrew Haley]

On 1/27/20 3:13 PM, Alex Scheel wrote:
> N.B.: I'd like to thank the Red Hat JVM team for being solid in
> their Fedora execution. But they maintain only the JVM, and not
> the rest of the Java ecosystem. :-)

Thank you.

One (perhaps) rather minor point in the middle of this important
discussion: there is no "Red Hat JVM team." We're responsible for the
entire base Java (SE) platform, that is to say the VM and the
surrounding Java libraries.

Also, we're not just responsible for RHEL and Fedora: our team and our
partners in a few other organizations are responsible for all OpenJDK
updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
to say, apart from Oracle's proprietary customers, most of the Java in
the world.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Christophe de Dinechin]

> On 28 Jan 2020, at 11:32, Guido Aulisi  wrote:
> 
> Il giorno mar 28 gen 2020 alle ore 10:04 Richard W.M. Jones
>  ha scritto:
>> 
>> I always think that Fedora works fine if you maintain 1-5 packages.
>> It's possible to maintain 20 with a lot of work.  And if you want to
>> maintain 100+ (things like the ocaml-* set that I help to maintain)
>> then you have to write your own automation.  Could we do things
>> better?  No one asked for them, but here are my ideas ...
>> 
>> ---
>> 
>> * kill the %changelog
>> 
>> Please, let's kill it, and generate it from the git changelog.
>> I'm glad to see there's a proposal to do this.
>> 
>> A general principle I'm following here is a packager should never
>> be asked to enter the same information twice.
>> 
>> * committing to git should build the package
>> 
>> Is there a reason why this wouldn't be the case?
> 
> Sometimes you only add comments to the spec file and a rebuild is not needed.

You don’t know that. What if you accidentally insert a newline in your comment?

> 
> Ciao
> Guido
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Christophe de Dinechin]

> On 28 Jan 2020, at 10:03, Richard W.M. Jones  wrote:
> 
> I always think that Fedora works fine if you maintain 1-5 packages.
> It's possible to maintain 20 with a lot of work.  And if you want to
> maintain 100+ (things like the ocaml-* set that I help to maintain)
> then you have to write your own automation.  Could we do things
> better?  No one asked for them, but here are my ideas ...
> 
> ---
> 
> * kill the %changelog
> 
> Please, let's kill it, and generate it from the git changelog.
> I'm glad to see there's a proposal to do this.
> 
> A general principle I'm following here is a packager should never
> be asked to enter the same information twice.

Right now, you can do it the other way round, i.e. update the
change log and fedpkg commit -c. But it is not very logical, and
I agree it would be more logical to deduce the change log from
the commit messages.

> 
> * committing to git should build the package
> 
> Is there a reason why this wouldn't be the case?
> 
> * commit groups of packages together
> 
> One reason why automatic commit -> build might not be desirable is if
> you're trying to build a group of packages in a side tag.  In my
> opinion this means we should allow groups of packages to be committed
> together.  (Unfortunately because we chose to put every package in its
> own git repo, the obvious way to do this can't work, but we could
> still have a "ChangeId:" header in the commit message that ties
> packages together).
> 
> The packages should be built in build dependency order into a side
> tag, and the side tag turned into an update, with no further
> involvement from the packager unless something fails to build.
> 
> This change on its own would solve the main problem that
> affects people maintaining large sets of packages.
> 
> * “Fixes:” etc headers in git
> 
> RHEL already does this.  It should be possible to add special headers
> to the commit message to automatically close bugs, ie:
> 
>  $ git commit -m "ocaml: Update to version 4.10.0
>  Fixes: RHBZ#12345"
> 
> Note the build, update and bug closing would happen completely
> automatically, assuming there was no build or test failure.
> 
> * CVE bugs should autoclose when a package is rebased
> 
> Fabiano built the mingw-openssl package recently, but there are still
> a load of open CVE bugs against this package referring to the older
> version.  These should be closed automatically.  I think this will
> require collecting the version of the package that fixes a CVE and
> recording that in Bugzilla (or in the package itself in some standard
> way).
> 
> * create streams of packages automatically depending on quality scores
> 
> We know a lot about packages such as:
> 
>  - How many bugs are opened against them?
>  - What's the average time between a bug being filed and fixed?
>  - Do they get regularly updated?
>  - Do they pass or fail CI tests?
>  - How many rpmlint / fedora-packager problems do they have?
> 
> Why don't we use that data to build streams of high quality and lesser
> quality packages?  Allow the end users to choose whether they want the
> best curated packages only, or they're prepared to accept the risk of
> taking a package with lots of bugs or CVEs (this is assuming the
> previous point is fixed, so these are real CVEs, not irrelevant bugs).
> 
> If you want to go even further with this idea, then it could even be
> possible we allow packages into Fedora without any review.  They would
> start in the outermost stream in a "there be dragons" repository that
> only the foolhardy would enable, but as their quality improved they
> would *automatically* migrate into the mainstream.
> 
> ---
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Christophe de Dinechin]

> On 29 Jan 2020, at 00:26, Robert-André Mauchin  wrote:
> 
> On Tuesday, 28 January 2020 10:03:09 CET Richard W.M. Jones wrote:
>> * committing to git should build the package
>> 
>> Is there a reason why this wouldn't be the case?
> 
> Please no. Sometimes you just fix a typo or add a comment and there's no need 
> to rebuild until a next release.

This “sometimes" is the rare case. So having a “push —nobuild” would address 
that need.

> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Iñaki Ucar]

On Wed, 29 Jan 2020 at 00:08, Leigh Griffin  wrote:
>
> On Tue, Jan 28, 2020, 22:06 Iñaki Ucar  wrote:
>>
>> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin  wrote:
>> >
>> > This thread is serving as a source of requirements (although it has 
>> > meandered dramatically away from that)
>>
>> When I first read the post, my thought was: wow, what a convoluted and
>> abstruse way of saying "we want to abandon Pagure". Probably this
>> wasn't your intent, but that's what I got. And given the reactions,
>> other people too.
>
> The linked blog to the ODF is very explicit that Pagure is one of the 3 forge 
> options we are considering. I can't stress enough that it's a viable choice 
> and ultimately what we opt for will come down to an analysis driven by the 
> requirements gathered. I'm unsure how the blog has been interpreted any other 
> way but hopefully this clears it up.

The ODF is very explicit in the problem statement, and it specifically
and clearly says that:

1. Pagure does not align with CPE.
2. CPE is not gonna commit a development team to Pagure.
3. The feature gap is big and growing, and basically Pagure is gonna
die because of this (and the document goes on saying that you're not
trying to solve the feature gap).

Then the ODF lists Pagure as a solution. How am I supposed to
interpret the above?

> If you (and others) elaborate on how you use Pagure (and other forges) and 
> what you value from your day to day usage, we will take that on board and use 
> it to drive our decision making.

Asking for requirements for a *forge* is pointless. A forge doesn't
have requirements. What you do with a forge has requirements. As
others have already pointed out, Pagure is being used at the very
least for 3 distinct use cases: to maintain rpm packages, to maintain
upstream projects, and as an issue tracker. And they all have distinct
requirements. Only that, as it happens, Pagure has grown to cover
their necessities with more or less success, which doesn't necessarily
mean that a forge is the best solution for all of them (as, again,
others have pointed out already). But the ODF only lists forges as
solutions.

So solutions for what? What are we talking about here? Requirements
for src.fp.org? Requirements for things that are in pagure.io? All?
Other?

Iñaki
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [security] only latest Qt 5.14.1 has all fixes

[Damian Ivanov]

But it's not the only CVE fixed with Qt 5.14.1
The point is that there is other software using Qt which doesn't start with
K even though K works just fine with 5.14 by the experience of other
distributions.

Though all software is affected by security issues by using unpatched Qt.

Affected by these new circumstances is not only @fedoraproject but as a
bonus also rhel / centos unless RH is paying to Qt for the LTS or RH
backports or provide latest Qt (at least very soon regarding the LTS)

The best approach is probably to provide a repo with the latest Qt version
for fedora, whoever wants to use their security free old tested version can
do so and others can use the newest secure upstream Qt version. As a former
user of openSUSE I gotta say that they have solved this very elegantly.
Multiple repos for example for Qt are created easily. You can even bump
version numbers or do simple changes to spec files from your phone or any
other web capable host, a very welcoming build system, back than with OBS
as openSUSE user I was maintaining more than a dozen of packages.

I will be gathering a list of all the CVE's later that would need to be
backported (to 5.12 and Qt 5.13) unless there is another solution, although
I think crash fixes should be backported as well, as there is no option to
use a good Qt version on Fedora, whereas other distributions do provide an
option to use a secure Qt version, maybe a public comparison is needed.

BR,
Damian


On Tue, 28 Jan 2020, 23:58 Rex Dieter,  wrote:

> Kevin Kofler wrote:
>
> > Rex Dieter wrote:
> >> Latest CVE there has a backported fix applied to fedora's packaging, and
> >> is currently in bodhi updates-testing,
> >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-9139ba5469
> >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-e9b85978d4
> >
> > But that's only QtBase. QtWebEngine has dozens of security fixes again in
> > 5.14.0 and 5.14.1 and our package is stuck on 5.13.2. (5.14.0 adds the
> > fixes from Chrom* 78, 5.14.1 the ones from Chrom* 79. 5.13.2 only has
> > security fixes up to Chrom* 77.)
>
> QtBase was the primary CVE mentioned in the original link.
>
> QtWebengine packaging is less restricted as far as updates and pretty sure
> that wasn't the point of the original post.
>
> -- Rex
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Damian Ivanov]

Maybe now that RH is part of IBM they have changed their short sighted view
of not collaborating on a better build system like OBS. As I recall back
than it was already able to bootstrap on centos and fedora and build
packages and the only argument against it was legacy support with mock /
koji which provide a fraction of functions that OBS does (mostly things
that make it easy to get new contributers like a web interface to edit spec
files and webhooks not to mention that these Mass rebuilt emails could be a
thing of the past).

On Wed, 29 Jan 2020, 12:17 Christophe de Dinechin, 
wrote:

>
>
> > On 29 Jan 2020, at 00:26, Robert-André Mauchin 
> wrote:
> >
> > On Tuesday, 28 January 2020 10:03:09 CET Richard W.M. Jones wrote:
> >> * committing to git should build the package
> >>
> >> Is there a reason why this wouldn't be the case?
> >
> > Please no. Sometimes you just fix a typo or add a comment and there's no
> need
> > to rebuild until a next release.
>
> This “sometimes" is the rare case. So having a “push —nobuild” would
> address that need.
>
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 11:36, Iñaki Ucar  wrote:

> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin  wrote:
> >
> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar  wrote:
> >>
> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin 
> wrote:
> >> >
> >> > This thread is serving as a source of requirements (although it has
> meandered dramatically away from that)
> >>
> >> When I first read the post, my thought was: wow, what a convoluted and
> >> abstruse way of saying "we want to abandon Pagure". Probably this
> >> wasn't your intent, but that's what I got. And given the reactions,
> >> other people too.
> >
> > The linked blog to the ODF is very explicit that Pagure is one of the 3
> forge options we are considering. I can't stress enough that it's a viable
> choice and ultimately what we opt for will come down to an analysis driven
> by the requirements gathered. I'm unsure how the blog has been interpreted
> any other way but hopefully this clears it up.
>
> The ODF is very explicit in the problem statement, and it specifically
> and clearly says that:
>
> 1. Pagure does not align with CPE.
> 2. CPE is not gonna commit a development team to Pagure.
> 3. The feature gap is big and growing, and basically Pagure is gonna
> die because of this (and the document goes on saying that you're not
> trying to solve the feature gap).
>
> Then the ODF lists Pagure as a solution. How am I supposed to
> interpret the above?
>

That the current situation is not ideal and before making any decisions it
is better to know exactly what are the use cases. It makes sense to keep
Pagure as a solution since we already know that it is matching most of
Fedora's needs, but Pagure has a few down side too and the main one is that
we have to develop and maintain it.  So while the current situation works,
it is not great. We might just find out that the other options are actually
worst, or not. To me that's the all point of this process, let's put down
what we *really* *really* need and  then look at the different options.

Also there are many possibilities, for example a group of people could step
up and take over the maintenance of Pagure so that CPE would just run the
instances, just like it is done with Koji. Or another distro, project could
be willing to use and contribute to Pagure so that we would share the
development and maintenance effort.  It is not forbidden to imagine such
possibilities :-)


>
> > If you (and others) elaborate on how you use Pagure (and other forges)
> and what you value from your day to day usage, we will take that on board
> and use it to drive our decision making.
>
> Asking for requirements for a *forge* is pointless. A forge doesn't
> have requirements. What you do with a forge has requirements.

As
> others have already pointed out, Pagure is being used at the very
> least for 3 distinct use cases: to maintain rpm packages, to maintain
> upstream projects, and as an issue tracker. And they all have distinct
> requirements. Only that, as it happens, Pagure has grown to cover
> their necessities with more or less success, which doesn't necessarily
> mean that a forge is the best solution for all of them (as, again,
> others have pointed out already). But the ODF only lists forges as
> solutions.
>
> So solutions for what? What are we talking about here? Requirements
> for src.fp.org? Requirements for things that are in pagure.io? All?
> Other?
>

My understanding is that we are looking at all use cases.


>
> Iñaki
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 01:09:04PM +0200, Damian Ivanov wrote:
>Maybe now that RH is part of IBM they have changed their short sighted
>view of not collaborating on a better build system like OBS. As I recall

And ... you lost me right there...


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Bill Chatfield via devel]

 That's one of the big reasons I like Red Hat. You guys rock!  :-)

On Wednesday, January 29, 2020, 5:14:18 AM EST, Andrew Haley 
 wrote:  
 
 On 1/27/20 3:13 PM, Alex Scheel wrote:
> N.B.: I'd like to thank the Red Hat JVM team for being solid in
> their Fedora execution. But they maintain only the JVM, and not
> the rest of the Java ecosystem. :-)

Thank you.

One (perhaps) rather minor point in the middle of this important
discussion: there is no "Red Hat JVM team." We're responsible for the
entire base Java (SE) platform, that is to say the VM and the
surrounding Java libraries.

Also, we're not just responsible for RHEL and Fedora: our team and our
partners in a few other organizations are responsible for all OpenJDK
updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
to say, apart from Oracle's proprietary customers, most of the Java in
the world.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Remi Collet]

Le 28/01/2020 à 10:03, Richard W.M. Jones a écrit :
> I always think that Fedora works fine if you maintain 1-5 packages.
> It's possible to maintain 20 with a lot of work.  And if you want to
> maintain 100+ (things like the ocaml-* set that I help to maintain)
> then you have to write your own automation.  Could we do things
> better?  No one asked for them, but here are my ideas ...

I'm probably one of the 100+ packages maintainers...

> ---
> 
> * kill the %changelog
> 
> Please, let's kill it, and generate it from the git changelog.
> I'm glad to see there's a proposal to do this.

Please no.

Yes, I probably the only one to not sync all branches
to have different changelog, and I also don't want
the mass-rebuild stuff there.

Simple proposal, we have rpmdev-bumpspec, improve it to retrieve
information from git log is you want to use it.

> A general principle I'm following here is a packager should never
> be asked to enter the same information twice.

There are different:

* Changelog is for end user
* Git log is for package maintainer

> * committing to git should build the package
> 
> Is there a reason why this wouldn't be the case?

Yes, because I often commit various changse "before" the build
(some being cherry-pick on other branch, some not)




IMHO, remember KISS, and don't try to add more magic to our tooling

And I really prefer to see stabilization of our current tools and
infrastructure before breaking it again.




Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Julen Landa Alustiza]

(snip)

20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this 
process, let's put down what we *really* *really* need and  then look at 
the different options.




Do we *really* *really* need to compete with other full featured git 
forges on features? The ODF says that this is one of the problem. Well, 
imo we don't *really* *really* need to compete with them.


Actually we already have the features that we *really* *really* need. 
Otherwise we could not release fedora using pagure as we are using, 
could we? :)


Regards,
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Stephen John Smoogen]

On Wed, 29 Jan 2020 at 06:10, Damian Ivanov  wrote:
>
> Maybe now that RH is part of IBM they have changed their short sighted view 
> of not collaborating on a better build system like OBS.

That is looking for a boogeyman under the bed to blame something that
has a long long history of not happening. Ever since OBS has been out,
there has been a yearly 'why isn't Fedora moving to OBS' thread
somewhere and there have been long lists of 'why we aren't' over and
over again. It has nothing to do with being part of IBM and a lot
about

1. Moving to OBS would have required rewriting a lot of spec files to
match what OBS looked for (this has gotten better over time but some
rewrite would be needed).
2. Different needs of the build system. The koji system has an
accounting logic which is tied into giving certain assurances about
when, where, who, and how software was compiled. OBS has different
accounting logic. You either have to spend a long time trying to
figure out how to convert the two, or dump one and start over with
OBS. Then you are pretty much starting a new operating system.
3. Changes occur by the people who put the work in. The people who are
spending 60-80 hours a week trying to keep Fedora compiling and
running know Koji. If another group wants to set up and run OBS to
make their own OS, they need to show up with the hardware, storage,
and time to do so because there is no slack with current people,
hardware, storage to stop running Koji.
4. Creative differences which are a fine line from Not Invented Here
but still exist.

We tend to focus on 4 a lot in these conversations because it makes
for the most 'fun' drama. We tend to ignore 2 and 3 because they are
'someone else's problem' that could become our own if we let it. The
problem is that 4 is a molehill and 1,2,3 are mountains of different
heights.


> As I recall back than it was already able to bootstrap on centos and fedora 
> and build packages and the only argument against it was legacy support with 
> mock / koji which provide a fraction of functions that OBS does (mostly 
> things that make it easy to get new contributers like a web interface to edit 
> spec files and webhooks not to mention that these Mass rebuilt emails could 
> be a thing of the past).
>
> On Wed, 29 Jan 2020, 12:17 Christophe de Dinechin,  
> wrote:
>>
>>
>>
>> > On 29 Jan 2020, at 00:26, Robert-André Mauchin  wrote:
>> >
>> > On Tuesday, 28 January 2020 10:03:09 CET Richard W.M. Jones wrote:
>> >> * committing to git should build the package
>> >>
>> >> Is there a reason why this wouldn't be the case?
>> >
>> > Please no. Sometimes you just fix a typo or add a comment and there's no 
>> > need
>> > to rebuild until a next release.
>>
>> This “sometimes" is the rare case. So having a “push —nobuild” would address 
>> that need.
>>
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct: 
>> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives: 
>> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
> (snip)
> 
> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> >To me that's the all point of this process, let's put down what we
> >*really* *really* need and  then look at the different options.
> >
> 
> Do we *really* *really* need to compete with other full featured git
> forges on features? The ODF says that this is one of the problem.
> Well, imo we don't *really* *really* need to compete with them.
> 
> Actually we already have the features that we *really* *really*
> need. Otherwise we could not release fedora using pagure as we are
> using, could we? :)

So let's revert the question, pagure does the what it needs to do and enough of
it, otherwise we would not be using it.

What does pagure miss that other solutions have and that could be considered a
requirement?

It could be that we don't **need** pagure to do anything more than what it does
today, which moves the discussion off a technical ground.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Damian Ivanov]

On Wed, Jan 29, 2020 at 4:05 PM Pierre-Yves Chibon  wrote:
> And ... you lost me right there...
> Pierre

That's too bad. Even If it's sounds harsh it's the reality.
It has been discussed before and there was no technical reason not to.

Just someone going for a short term solution.
Maybe it is time for someone who works at redhat to stand up going to
the manager dude or dudeline
(which is a support role just like HR btw.)
and explain why the current solution is/has/will(be-en) inferior,and
is hurtful to the Linux
ecosystem as a whole and a very bad long term solution. The only thing
that is at the same time a plus and a minus
for a rh manager would be that other distributions will benefit as
well (and maybe giving credit to someone else as it was not developed
in house).

Anyone who spends objectively more than 30 minutes with the two
systems will understand and be able to confirm.
OBS is an example of KISS. The web interface attracting contributors.
Different repo's for different versions and build
targets like Qt could use currently. Compare COPR with OBS.

Some people may not like the sound of that but I believe that every
word of that is true.

Br,
Damian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon  wrote:
>
> On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
> > (snip)
> >
> > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > >To me that's the all point of this process, let's put down what we
> > >*really* *really* need and  then look at the different options.
> > >
> >
> > Do we *really* *really* need to compete with other full featured git
> > forges on features? The ODF says that this is one of the problem.
> > Well, imo we don't *really* *really* need to compete with them.
> >
> > Actually we already have the features that we *really* *really*
> > need. Otherwise we could not release fedora using pagure as we are
> > using, could we? :)
>
> So let's revert the question, pagure does the what it needs to do and enough 
> of
> it, otherwise we would not be using it.
>
> What does pagure miss that other solutions have and that could be considered a
> requirement?
>
> It could be that we don't **need** pagure to do anything more than what it 
> does
> today, which moves the discussion off a technical ground.
>

From a Dist-Git perspective, there is are two things I need:
* per-branch ACLs
* the ability to set bugzilla owners without granting commit access.

The first thing is because I get nervous granting people access to the
Git project who want to build EPEL8 packages but clearly aren't good
at managing Git workflows. I don't want them breaking my workflows
with Fedora packages.

The second thing is because there are a number of packages that I
maintain where upstream would like to be notified on bugzilla bugs but
not otherwise be involved in packaging. Pagure itself has the ticket
ACL for this, but I don't think this does anything in the Dist-Git
setup.

From the Git forge perspective, the two big things I need are:
* working self-service CI
* workflow for self-service integration management per-user and per-repo

The first item is because the current Pagure CI with CentOS CI Jenkins
is inexcusably bad. Jenkins is often unresponsive and broken, and
configuring it requires manual intervention from the CentOS CI folks.
Part of the reason we have Pagure was to move to more of a
self-service model, and our default offering for CI services fails at
that.

The second item is because there are an array of third party Free
Software services out there that people should be able to use without
having to talk to the Pagure admin to activate or enable. We do have
webhooks for basic integrations, but doing authentication and
authorization flows for generating app tokens and such is something we
don't have today. Having this would allow far more sophisticated
integrations than what we have now without always having to involve an
admin over it.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 09:37:36AM -0500, Neal Gompa wrote:
> On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon  
> wrote:
> >
> > On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
> > > (snip)
> > >
> > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > > >To me that's the all point of this process, let's put down what we
> > > >*really* *really* need and  then look at the different options.
> > > >
> > >
> > > Do we *really* *really* need to compete with other full featured git
> > > forges on features? The ODF says that this is one of the problem.
> > > Well, imo we don't *really* *really* need to compete with them.
> > >
> > > Actually we already have the features that we *really* *really*
> > > need. Otherwise we could not release fedora using pagure as we are
> > > using, could we? :)
> >
> > So let's revert the question, pagure does the what it needs to do and 
> > enough of
> > it, otherwise we would not be using it.
> >
> > What does pagure miss that other solutions have and that could be 
> > considered a
> > requirement?
> >
> > It could be that we don't **need** pagure to do anything more than what it 
> > does
> > today, which moves the discussion off a technical ground.
> >
> 
> From a Dist-Git perspective, there is are two things I need:
> * per-branch ACLs
> * the ability to set bugzilla owners without granting commit access.
> 
> The first thing is because I get nervous granting people access to the
> Git project who want to build EPEL8 packages but clearly aren't good
> at managing Git workflows. I don't want them breaking my workflows
> with Fedora packages.
> 
> The second thing is because there are a number of packages that I
> maintain where upstream would like to be notified on bugzilla bugs but
> not otherwise be involved in packaging. Pagure itself has the ticket
> ACL for this, but I don't think this does anything in the Dist-Git
> setup.

If they have a FAS account, they can go to dist-git: Watch issues on the package
and they will be added to the CC list on bugzilla.


We are working on moving off the bugzilla overrides from the scm-requests git
repo into pagure, like we did for the anitya integration.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Damian Ivanov]

>That is looking for a boogeyman under the bed to blame something that
>has a long long history of not happening. Ever since OBS has been out,
>there has been a yearly 'why isn't Fedora moving to OBS' thread

It has always been a bad management decision to not change.
Ever since OBS has been out there has been a regular thread about this
(usually not started by me), because it's the correct thing to do in
a long term perspective for RH and the Linux community/ecosystem.

On Wed, Jan 29, 2020 at 4:26 PM Stephen John Smoogen  wrote:
>
> On Wed, 29 Jan 2020 at 06:10, Damian Ivanov  wrote:
> >
> > Maybe now that RH is part of IBM they have changed their short sighted view 
> > of not collaborating on a better build system like OBS.
>
> That is looking for a boogeyman under the bed to blame something that
> has a long long history of not happening. Ever since OBS has been out,
> there has been a yearly 'why isn't Fedora moving to OBS' thread
> somewhere and there have been long lists of 'why we aren't' over and
> over again. It has nothing to do with being part of IBM and a lot
> about
>
> 1. Moving to OBS would have required rewriting a lot of spec files to
> match what OBS looked for (this has gotten better over time but some
> rewrite would be needed).
> 2. Different needs of the build system. The koji system has an
> accounting logic which is tied into giving certain assurances about
> when, where, who, and how software was compiled. OBS has different
> accounting logic. You either have to spend a long time trying to
> figure out how to convert the two, or dump one and start over with
> OBS. Then you are pretty much starting a new operating system.
> 3. Changes occur by the people who put the work in. The people who are
> spending 60-80 hours a week trying to keep Fedora compiling and
> running know Koji. If another group wants to set up and run OBS to
> make their own OS, they need to show up with the hardware, storage,
> and time to do so because there is no slack with current people,
> hardware, storage to stop running Koji.
> 4. Creative differences which are a fine line from Not Invented Here
> but still exist.
>
> We tend to focus on 4 a lot in these conversations because it makes
> for the most 'fun' drama. We tend to ignore 2 and 3 because they are
> 'someone else's problem' that could become our own if we let it. The
> problem is that 4 is a molehill and 1,2,3 are mountains of different
> heights.
>
>
> > As I recall back than it was already able to bootstrap on centos and fedora 
> > and build packages and the only argument against it was legacy support with 
> > mock / koji which provide a fraction of functions that OBS does (mostly 
> > things that make it easy to get new contributers like a web interface to 
> > edit spec files and webhooks not to mention that these Mass rebuilt emails 
> > could be a thing of the past).
> >
> > On Wed, 29 Jan 2020, 12:17 Christophe de Dinechin,  
> > wrote:
> >>
> >>
> >>
> >> > On 29 Jan 2020, at 00:26, Robert-André Mauchin  wrote:
> >> >
> >> > On Tuesday, 28 January 2020 10:03:09 CET Richard W.M. Jones wrote:
> >> >> * committing to git should build the package
> >> >>
> >> >> Is there a reason why this wouldn't be the case?
> >> >
> >> > Please no. Sometimes you just fix a typo or add a comment and there's no 
> >> > need
> >> > to rebuild until a next release.
> >>
> >> This “sometimes" is the rare case. So having a “push —nobuild” would 
> >> address that need.
> >>
> >> >
> >> > ___
> >> > devel mailing list -- devel@lists.fedoraproject.org
> >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> > Fedora Code of Conduct: 
> >> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> > List Archives: 
> >> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fed

Re: Java Dev Group and Fedora Quality

[Stephen John Smoogen]

On Wed, 29 Jan 2020 at 05:14, Andrew Haley  wrote:
>
> On 1/27/20 3:13 PM, Alex Scheel wrote:
> > N.B.: I'd like to thank the Red Hat JVM team for being solid in
> > their Fedora execution. But they maintain only the JVM, and not
> > the rest of the Java ecosystem. :-)
>
> Thank you.
>
> One (perhaps) rather minor point in the middle of this important
> discussion: there is no "Red Hat JVM team." We're responsible for the
> entire base Java (SE) platform, that is to say the VM and the
> surrounding Java libraries.
>
> Also, we're not just responsible for RHEL and Fedora: our team and our
> partners in a few other organizations are responsible for all OpenJDK
> updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
> to say, apart from Oracle's proprietary customers, most of the Java in
> the world.
>

The issue is that people (developers, users, maintainers) lump the
entire ecosystem together.. so yes you maintain that but why don't you
also maintain all the java packages which sit on that platform so it
is 'useful' to them. [Yes the question is one of scope, time and
resources.. but to a lot of people it needs clear explanations in the
same way that people will take their Ford to a Toyoto autoshop because
'its a car, you should be able to fix it']



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza 
wrote:

> (snip)
>
> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > To me that's the all point of this
> > process, let's put down what we *really* *really* need and  then look at
> > the different options.
> >
>
> Do we *really* *really* need to compete with other full featured git
> forges on features? The ODF says that this is one of the problem. Well,
> imo we don't *really* *really* need to compete with them.
>

It depends on the use case, doing development work projects hosted on
pagure.io is not great in my opinion. In particular working with pull
requests.

In terms of issue trackers, it is missing the ability to visualize issues
in a board for example.
Again this my opinion and maybe these are maybe not *really* *really*
needed.


> Actually we already have the features that we *really* *really* need.
> Otherwise we could not release fedora using pagure as we are using,
> could we? :)
>

I personally don't think we can release Fedora without people across the
project doing heroics and a crazy amount of hours which seems to have
become a norm rather than an exception.



> Regards,
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Julen Landa Alustiza]

Per git ref acls is not a common thing on git forges. If this is a final 
requirement, we should start analyzing the viability of implementing and 
maintain it on the different forges (and it should be feasible with all of the 
rest of our strange ACLs on dist-git)

On pagure side, now that our downstream instances are not using gitolite, 
implementing them needs much less work that migrating all our toolings to other 
solutions.

2020(e)ko urtarrilaren 29(a) 15:37:36 (CET)-(e)an, Neal Gompa 
-(e)k hau idatzi zuen:
>On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon
> wrote:
>>
>> On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
>> > (snip)
>> >
>> > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>> > >To me that's the all point of this process, let's put down what we
>> > >*really* *really* need and  then look at the different options.
>> > >
>> >
>> > Do we *really* *really* need to compete with other full featured
>git
>> > forges on features? The ODF says that this is one of the problem.
>> > Well, imo we don't *really* *really* need to compete with them.
>> >
>> > Actually we already have the features that we *really* *really*
>> > need. Otherwise we could not release fedora using pagure as we are
>> > using, could we? :)
>>
>> So let's revert the question, pagure does the what it needs to do and
>enough of
>> it, otherwise we would not be using it.
>>
>> What does pagure miss that other solutions have and that could be
>considered a
>> requirement?
>>
>> It could be that we don't **need** pagure to do anything more than
>what it does
>> today, which moves the discussion off a technical ground.
>>
>
>From a Dist-Git perspective, there is are two things I need:
>* per-branch ACLs
>* the ability to set bugzilla owners without granting commit access.
>
>The first thing is because I get nervous granting people access to the
>Git project who want to build EPEL8 packages but clearly aren't good
>at managing Git workflows. I don't want them breaking my workflows
>with Fedora packages.
>
>The second thing is because there are a number of packages that I
>maintain where upstream would like to be notified on bugzilla bugs but
>not otherwise be involved in packaging. Pagure itself has the ticket
>ACL for this, but I don't think this does anything in the Dist-Git
>setup.
>
>From the Git forge perspective, the two big things I need are:
>* working self-service CI
>* workflow for self-service integration management per-user and
>per-repo
>
>The first item is because the current Pagure CI with CentOS CI Jenkins
>is inexcusably bad. Jenkins is often unresponsive and broken, and
>configuring it requires manual intervention from the CentOS CI folks.
>Part of the reason we have Pagure was to move to more of a
>self-service model, and our default offering for CI services fails at
>that.
>
>The second item is because there are an array of third party Free
>Software services out there that people should be able to use without
>having to talk to the Pagure admin to activate or enable. We do have
>webhooks for basic integrations, but doing authentication and
>authorization flows for generating app tokens and such is something we
>don't have today. Having this would allow far more sophisticated
>integrations than what we have now without always having to involve an
>admin over it.
>
>
>-- 
>真実はいつも一つ！/ Always, there's only one truth!
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct:
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives:
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

--
Julen Landa Alustiza ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Randy Barlow]

On Wed, 2020-01-29 at 09:43 +, Richard W.M. Jones wrote:
> Also AIUI fedpkg chain-build doesn't work except in
> Rawhide, although I'm not sure why that is?

It doesn't work in stable because you need to create buildroot
overrides for each dependency before you can proceed with building the
next package, and fedpkg chain-build doesn't create the BROs.

However, I think the multi-package gating can do this now that it
exists, because AFAIK you should be able to chain-build in a side tag.
I have not tried this yet.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 10:07:55AM -0500, Randy Barlow wrote:
> On Wed, 2020-01-29 at 09:43 +, Richard W.M. Jones wrote:
> > Also AIUI fedpkg chain-build doesn't work except in
> > Rawhide, although I'm not sure why that is?
> 
> It doesn't work in stable because you need to create buildroot
> overrides for each dependency before you can proceed with building the
> next package, and fedpkg chain-build doesn't create the BROs.
> 
> However, I think the multi-package gating can do this now that it
> exists, because AFAIK you should be able to chain-build in a side tag.
> I have not tried this yet.

It's less the gating itself than the work done to support mulit-builds updates
gating, where we introduced on-demand side-tag which are available in rawhide as
well as stable releases.
Thus you can now use fedpkg chain-build and point it to your side-tag in any
Fedora release.

The only thing to be aware of with stable releases is that the side-tag will be
removed once an update is created for it.
So if you need to add a build to the update, you'll have to go back to the
buildroot overrides.


Pierre


pgpLqlSaKv6Wm.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar  wrote:

> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin  wrote:
> >
> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar  wrote:
> >>
> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin 
> wrote:
> >> >
> >> > This thread is serving as a source of requirements (although it has
> meandered dramatically away from that)
> >>
> >> When I first read the post, my thought was: wow, what a convoluted and
> >> abstruse way of saying "we want to abandon Pagure". Probably this
> >> wasn't your intent, but that's what I got. And given the reactions,
> >> other people too.
> >
> > The linked blog to the ODF is very explicit that Pagure is one of the 3
> forge options we are considering. I can't stress enough that it's a viable
> choice and ultimately what we opt for will come down to an analysis driven
> by the requirements gathered. I'm unsure how the blog has been interpreted
> any other way but hopefully this clears it up.
>
> The ODF is very explicit in the problem statement, and it specifically
> and clearly says that:
>
> 1. Pagure does not align with CPE.
>

Correct and it's why we said this line, which you might have missed:
"While we can make exceptions to the mission statement, we first need to
know why we should consider a specific exception."


> 2. CPE is not gonna commit a development team to Pagure.
>

CPE has not committed a team to it in over a year, we do state that as a
driving factor to why we want to engage in this conversation but your
assumption here is based on a particular outcome that sees Pagure not
chosen. If Pagure is chosen, we will commit a team. We are very clear on
that.


> 3. The feature gap is big and growing, and basically Pagure is gonna
> die because of this (and the document goes on saying that you're not
> trying to solve the feature gap).
>

Pagure is a standalone community project. Our choice is not killing Pagure
and irrespective of the decision we make I personally hope it stays strong
and grows. Stating the feature gap is big and growing is factual, with no
committed team we are behind on it.

>
> Then the ODF lists Pagure as a solution. How am I supposed to
> interpret the above?
>


This is why we are opening it to be very explicit that for the past year we
have not focused on Pagure but we now need to make a decision going
forward. If Pagure is the choice we staff it accordingly and
de-priortise other initiatives and include it within our scope going
forward. That is why Pagure is listed as a choice and it is why the ODF is
laid out like that.


>
> > If you (and others) elaborate on how you use Pagure (and other forges)
> and what you value from your day to day usage, we will take that on board
> and use it to drive our decision making.
>
> Asking for requirements for a *forge* is pointless. A forge doesn't
> have requirements. What you do with a forge has requirements.


Tell me what you do and how you interact with a forge? That's the point of
this exercise.


> As
> others have already pointed out, Pagure is being used at the very
> least for 3 distinct use cases: to maintain rpm packages, to maintain
> upstream projects, and as an issue tracker. And they all have distinct
> requirements.


And we wish to hear all 3 as ultimately CPE become the owner of the
solution that satisfies those requirements.


> Only that, as it happens, Pagure has grown to cover
> their necessities with more or less success, which doesn't necessarily
> mean that a forge is the best solution for all of them (as, again,
> others have pointed out already). But the ODF only lists forges as
> solutions.
>

And if the requirements are stated we can have an open conversation about
what does suit it. I get that things have organically grown around a forge
that may / may not be the best fit for it now, lets examine that as a
conversation when we know how people are using it. This topic is focused on
what git forge the CPE team will choose based on requirements gathered but
if there is a means to address a requirement gap by another tool that is
not a forge, then that's a really good outcome of the conversation.

>
> So solutions for what? What are we talking about here? Requirements
> for src.fp.org? Requirements for things that are in pagure.io? All?
> Other?
>
> Iñaki
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs

Re: Java Dev Group and Fedora Quality

[Alex Scheel]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, January 29, 2020 8:47:46 AM
> Subject: Re: Java Dev Group and Fedora Quality
> 
> On Wed, 29 Jan 2020 at 05:14, Andrew Haley  wrote:
> >
> > On 1/27/20 3:13 PM, Alex Scheel wrote:
> > > N.B.: I'd like to thank the Red Hat JVM team for being solid in
> > > their Fedora execution. But they maintain only the JVM, and not
> > > the rest of the Java ecosystem. :-)
> >
> > Thank you.
> >
> > One (perhaps) rather minor point in the middle of this important
> > discussion: there is no "Red Hat JVM team." We're responsible for the
> > entire base Java (SE) platform, that is to say the VM and the
> > surrounding Java libraries.
> >
> > Also, we're not just responsible for RHEL and Fedora: our team and our
> > partners in a few other organizations are responsible for all OpenJDK
> > updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
> > to say, apart from Oracle's proprietary customers, most of the Java in
> > the world.
> >
> 
> The issue is that people (developers, users, maintainers) lump the
> entire ecosystem together.. so yes you maintain that but why don't you
> also maintain all the java packages which sit on that platform so it
> is 'useful' to them. [Yes the question is one of scope, time and
> resources.. but to a lot of people it needs clear explanations in the
> same way that people will take their Ford to a Toyoto autoshop because
> 'its a car, you should be able to fix it']

Right Andrew: Stephen was drawing the distinction I was trying to make.
I lump the Java SE platform into "roughly" what I was calling the JVM
team. You're roughly the group that does what'd be the "core" work in
other languages: maintains the compilers and the stdlib. My terminology
there was incorrect; I suppose "JRE" is more correct.

Is it correct to say that your team and immediate coworkers don't
maintain say, the Apache libraries, the various build systems, IDEs,
and the JBoss libraries? 

My point is that some language SIGs/teams take a more active role in
making sure a decent amount of non-stdlib software runs and is
maintained by them. The "core" Java (JVM + JRE) team doesn't seem to
engage in other places. Which is totally fine, from my PoV, as long
as there is communication between the two parts and between the group
and the wider Fedora community, and the overall experience is inclusive.


Instead, most of the library support falls to Joe's team, including
Mikolaj. That's where most of the shortcomings in Java packaging are
seen, including unfriendly, non-inclusive modularization policies.
They're the ones that have orphaned large segments of packages, which
ultimately lead to starting this mail thread. :-)

Perhaps putting words in Bill's mouth here, but I don't subscribe any
of his issues to the JRE team. They're mostly caused by issues in a
lot of packages disappearing, and Matt Booth trying his best to clean
up after that (with the help of Stewardship SIG). But we're all busy
folks and sometimes we can handle that new package load and sometimes
we can't.


And yes, you do a lot of great work in other places too. I thank you
for that the few times I need to touch Java on non-Linux platforms. :-)


Keep up the good work,

- Alex

> 
> 
> 
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Julen Landa Alustiza]

2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna 
-(e)k hau idatzi zuen:
>On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
>
>wrote:
>
>> (snip)
>>
>> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>> > To me that's the all point of this
>> > process, let's put down what we *really* *really* need and  then
>look at
>> > the different options.
>> >
>>
>> Do we *really* *really* need to compete with other full featured git
>> forges on features? The ODF says that this is one of the problem.
>Well,
>> imo we don't *really* *really* need to compete with them.
>>
>
>It depends on the use case, doing development work projects hosted on
>pagure.io is not great in my opinion. In particular working with pull
>requests.
>
I don't have excesive problems with pagure on PR workflows. Right now for me 
centos-ci is a much bigger problem for PR workflows on pagure.io than pagure 
itself for example.

>In terms of issue trackers, it is missing the ability to visualize
>issues
>in a board for example.
>Again this my opinion and maybe these are maybe not *really* *really*
>needed.

Is a great forge the beste solution for this? Or are there other solutions for 
issue tracking/kanban/boards etc that could better suit this use cases?
>
>
>> Actually we already have the features that we *really* *really* need.
>> Otherwise we could not release fedora using pagure as we are using,
>> could we? :)
>>
>
>I personally don't think we can release Fedora without people across
>the
>project doing heroics and a crazy amount of hours which seems to have
>become a norm rather than an exception.
>
+1. But is this a git forge problem?

We are again on the same place: we have different use cases hosted on pagure. 
Some of them could need a big effort on pagure side to compete with other 
options (on technical features), some others could benefit of migrating to 
other solutions, and some others could not have a better solution than our own 
custom one

--
Julen Landa Alustiza 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
>On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
> wrote:
> 
>  (snip)
> 
>  20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  > To me that's the all point of this
>  > process, let's put down what we *really* *really* need and  then look
>  at
>  > the different options.
>  >
> 
>  Do we *really* *really* need to compete with other full featured git
>  forges on features? The ODF says that this is one of the problem. Well,
>  imo we don't *really* *really* need to compete with them.
> 
>It depends on the use case, doing development work projects hosted on
>pagure.io is not great in my opinion. In particular working with pull
>requests.
>In terms of issue trackers, it is missing the ability to visualize issues
>in a board for example. 
>Again this my opinion and maybe these are maybe not *really* *really*
>needed.
> 
>  Actually we already have the features that we *really* *really* need.
>  Otherwise we could not release fedora using pagure as we are using,
>  could we? :)
> 
>I personally don't think we can release Fedora without people across the
>project doing heroics and a crazy amount of hours which seems to have
>become a norm rather than an exception. 

I don't think anyone can disagree with this, but this begs the question: are
these heroics related to pagure?
If not, I'm not sure what is the point you were trying to make for this thread.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 04:06:22PM +0100, Julen Landa Alustiza wrote:
>Per git ref acls is not a common thing on git forges. If this is a final
>requirement, we should start analyzing the viability of implementing and
>maintain it on the different forges (and it should be feasible with all of
>the rest of our strange ACLs on dist-git)
> 
>On pagure side, now that our downstream instances are not using gitolite,
>implementing them needs much less work that migrating all our toolings to
>other solutions.

I believe, and Leigh correct me if I'm wrong, that this will be the next step in
the analysis.

1/ gather all the requirement
2/ figure out which option have which requirement
3/ figure out if it is "cheaper" to fix feature A in option 2, or add feature B
in option 3 or leave without feature C in option 1

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 29, 2020 at 10:07 AM Julen Landa Alustiza
 wrote:
>
> Per git ref acls is not a common thing on git forges. If this is a final 
> requirement, we should start analyzing the viability of implementing and 
> maintain it on the different forges (and it should be feasible with all of 
> the rest of our strange ACLs on dist-git)
>
> On pagure side, now that our downstream instances are not using gitolite, 
> implementing them needs much less work that migrating all our toolings to 
> other solutions.
>

It's usually called "branch protection" in GitHub and GitLab. The
functionality varies a bit, but the feature exists.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Wed, Jan 29, 2020 at 3:30 PM Pierre-Yves Chibon 
wrote:

> On Wed, Jan 29, 2020 at 04:06:22PM +0100, Julen Landa Alustiza wrote:
> >Per git ref acls is not a common thing on git forges. If this is a
> final
> >requirement, we should start analyzing the viability of implementing
> and
> >maintain it on the different forges (and it should be feasible with
> all of
> >the rest of our strange ACLs on dist-git)
> >
> >On pagure side, now that our downstream instances are not using
> gitolite,
> >implementing them needs much less work that migrating all our
> toolings to
> >other solutions.
>
> I believe, and Leigh correct me if I'm wrong, that this will be the next
> step in
> the analysis.
>
> 1/ gather all the requirement
> 2/ figure out which option have which requirement
> 3/ figure out if it is "cheaper" to fix feature A in option 2, or add
> feature B
> in option 3 or leave without feature C in option 1
>

Correct we will perform an analysis on the requirements Vs the offerings.
It then becomes a cost benefit analysis to build out (or acquire) feature A
at the cost of refactoring process B and so on. We will publish the wider
requirements and the analysis to help support a transparent decision.


>
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Stephen John Smoogen]

On Wed, 29 Jan 2020 at 09:46, Damian Ivanov  wrote:
>
> >That is looking for a boogeyman under the bed to blame something that
> >has a long long history of not happening. Ever since OBS has been out,
> >there has been a yearly 'why isn't Fedora moving to OBS' thread
>
> It has always been a bad management decision to not change.
> Ever since OBS has been out there has been a regular thread about this
> (usually not started by me), because it's the correct thing to do in
> a long term perspective for RH and the Linux community/ecosystem.
>

I think you are conflating management and leadership and assuming that
they have ever been 1:1 in Fedora or Red Hat.  For the most part
managers are people who push paperwork, attend meetings and do
whatever it is to allow the developers do what they feel is needed to
get an OS out the door. They also are used as a convenient fall-guy
when a developer doesn't really want to do something by saying
management decided something. [There have been many a time the manager
finds out about the decision at the same as the people being told a
decision was made.]

In the end, stuff gets done by leader's who commit to doing the lion's
share of the work. Sometimes it is a manager, but mostly it is by
various developers or maintainers who go ahead and make something
happen either by skunk-works or putting in enough that it is done. The
fact that OBS has not been chosen is more about no one wanting to do
all the hardwork to make it happen versus management saying 'its from
SuSE so we can't use it.'  The way things have worked instead is that
someone will say 'I want to show that this can be done with X' and
they will go and do a lot of the work to make that happen.
Mandrake(Mandriva? Mageia?) was started as  someone wanting Red Hat
Linux rebuilt with various Pentium+ flags versus i386. They also
wanted to show other things that the Red Hat Linux developers were not
comfortable with. Eventually that hard work was what got Red Hat Linux
to start adding in Pentium+ items and other things. The same with
various desktops.. in no case was it management saying 'dont do that'
it was developers saying 'I have enough work already and this isn't
going to make it less.' until it was less. OBS is fighting the 'Devil
I know versus the devil I don't know' with every Fedora developer who
knows fedpkg and the current tools. They may hate those tools, but
they know they work AND they know that maintenance and keeping them
working is somebody else's problem.

If people want to set up an OBS build system, they need to become the
people who that it is 'somebody else's problem' . They need to set up
a buildsystem, build the OS, document how it works and be pretty
honest about what doesn't. Then they will either get the old packagers
to try it out or a bunch of new ones to take up the burden.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Florian Weimer]

* Neal Gompa:

> On Wed, Jan 29, 2020 at 10:07 AM Julen Landa Alustiza
>  wrote:
>>
>> Per git ref acls is not a common thing on git forges. If this is a final 
>> requirement, we should start analyzing the viability of implementing and 
>> maintain it on the different forges (and it should be feasible with all of 
>> the rest of our strange ACLs on dist-git)
>>
>> On pagure side, now that our downstream instances are not using gitolite, 
>> implementing them needs much less work that migrating all our toolings to 
>> other solutions.
>>
>
> It's usually called "branch protection" in GitHub and GitLab. The
> functionality varies a bit, but the feature exists.

It's also sometimes enforced externally by bots which only perform
merges if they are requested by authorized developers (and nobody
updates refs directly under this model).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Adam Williamson]

On Wed, 2020-01-29 at 15:56 +0100, Clement Verna wrote:
> On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza 
> wrote:
> 
> > (snip)
> > 
> > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > > To me that's the all point of this
> > > process, let's put down what we *really* *really* need and  then look at
> > > the different options.
> > > 
> > 
> > Do we *really* *really* need to compete with other full featured git
> > forges on features? The ODF says that this is one of the problem. Well,
> > imo we don't *really* *really* need to compete with them.
> > 
> 
> It depends on the use case, doing development work projects hosted on
> pagure.io is not great in my opinion. In particular working with pull
> requests.

> In terms of issue trackers, it is missing the ability to visualize issues
> in a board for example.
> Again this my opinion and maybe these are maybe not *really* *really*
> needed.

I think it depends on the size and scope of your project a bit. I do
find Pagure.io a pretty good host of the projects I have there, as
they're fairly small. But then, an open source (non-enterprise edition)
Gitlab instance would work fine for them too.

> 
> > Actually we already have the features that we *really* *really* need.
> > Otherwise we could not release fedora using pagure as we are using,
> > could we? :)
> > 
> 
> I personally don't think we can release Fedora without people across the
> project doing heroics and a crazy amount of hours which seems to have
> become a norm rather than an exception.

When that happens it doesn't normally involve Pagure much, though. And
I don't think even an amazing git forge would actually go a long way to
solving the main issues there.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Adam Williamson]

On Wed, 2020-01-29 at 16:17 +0100, Julen Landa Alustiza wrote:
> 
> 2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna 
> -(e)k hau idatzi zuen:
> > On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
> > 
> > wrote:
> > 
> > > (snip)
> > > 
> > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > > > To me that's the all point of this
> > > > process, let's put down what we *really* *really* need and  then
> > look at
> > > > the different options.
> > > > 
> > > 
> > > Do we *really* *really* need to compete with other full featured git
> > > forges on features? The ODF says that this is one of the problem.
> > Well,
> > > imo we don't *really* *really* need to compete with them.
> > > 
> > 
> > It depends on the use case, doing development work projects hosted on
> > pagure.io is not great in my opinion. In particular working with pull
> > requests.
> > 
> I don't have excesive problems with pagure on PR workflows. Right now
> for me centos-ci is a much bigger problem for PR workflows on
> pagure.io than pagure itself for example.

So, there was an interesting talk at Devconf this year:

https://devconfcz2020a.sched.com/event/YOtV/cicd-for-fedora-packaging-with-zuul

summary: you can use Zuul as CI on Pagure. Both src.fp.o and pagure.io.
I set it up for a project with some help from Tristan Cacqueray over
the last couple of days, to try it out. It works, and it wasn't too
hard:

https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/140

that PR does a lot more than just set up the Zuul CI, but the point is
that it works, see the last couple of 'success'es. The failures were
teething troubles getting the CI setup right, but it was nothing too
major (mostly boiled down to the default environment being CentOS 7,
and that distro having a very old tox that doesn't have 'py37' and
'py38' as standard environments - we just had to tweak the config to
run the tests in a Fedora 31 environment instead).

The actual work to set up the CI was not too hard: send a pull request
to a special repo to 'enable' things:

https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/140

and then add just a couple of little files to the repo:

https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/5b518d107d62e0fa9462c4ef518d05b34758f65c/f/.zuul.yaml
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/05cfd0aff616e0216afa35a63ac875cd4cbbe88b/f/ci/tox.yaml

Obviously don't know if it's more reliable than CentOS CI yet as I
only just turned it on, but...I wouldn't bet against it :P
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [security] only latest Qt 5.14.1 has all fixes

[Rex Dieter]

Damian Ivanov wrote:

> But it's not the only CVE fixed with Qt 5.14.1
> The point is that there is other software using Qt which doesn't start
> with K even though K works just fine with 5.14 by the experience of other
> distributions.

Bumping Qt versions is... a fairly difficult process in fedora, 
unfortunately.  The primary reason is that there are many packages that use 
Qt private api's the require rebuilding for every release.  Quick check just 
now in rawhide is that a full Qt5 version update requires (re)building at 
least 78 packages.

So, we (kde-sign, Qt maintainers) generally update strategically where it 
makes sense to warrant the time investment in doing so.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon 
wrote:

> On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
> >On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
> > wrote:
> >
> >  (snip)
> >
> >  20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> >  > To me that's the all point of this
> >  > process, let's put down what we *really* *really* need and  then
> look
> >  at
> >  > the different options.
> >  >
> >
> >  Do we *really* *really* need to compete with other full featured git
> >  forges on features? The ODF says that this is one of the problem.
> Well,
> >  imo we don't *really* *really* need to compete with them.
> >
> >It depends on the use case, doing development work projects hosted on
> >pagure.io is not great in my opinion. In particular working with
> pull
> >requests.
> >In terms of issue trackers, it is missing the ability to visualize
> issues
> >in a board for example.Â
> >Again this my opinion and maybe these are maybe not *really* *really*
> >needed.
> >
> >  Actually we already have the features that we *really* *really*
> need.
> >  Otherwise we could not release fedora using pagure as we are using,
> >  could we? :)
> >
> >I personally don't think we can release Fedora without people across
> the
> >project doing heroics and a crazy amount of hours which seems to have
> >become a norm rather than an exception.Â
>
> I don't think anyone can disagree with this, but this begs the question:
> are

these heroics related to pagure?
>
If not, I'm not sure what is the point you were trying to make for this
> thread.
>

My point is that we have to dedicate a team to work on Pagure, I would
rather have these people working on improving the infrastructure so that we
don't need these heroics to happen. If we don't put people to work on
Pagure it will end up being another fedora-packages, badges or FAS and in
couple years it will be too difficult to do anything with it. It is not
only about Pagure, for example I would love to be able to replace Bodhi
with something that we don't have to maintain but it is much more difficult
to find an alternative to Bodhi than Pagure.

My general feeling is that an infrastructure team should avoid as much as
possible to maintain large applications, the focus should be to develop the
glue needed to for the different services to work together in the most
efficient manner, to monitor the applications, the respond to outages.

Does that clarify my thoughts ?


>
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Iñaki Ucar]

On Wed, 29 Jan 2020 at 16:23, Leigh Griffin  wrote:
>
> On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar  wrote:
>>
>> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin  wrote:
>> >
>> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar  wrote:
>> >>
>> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin  wrote:
>> >> >
>> >> > This thread is serving as a source of requirements (although it has 
>> >> > meandered dramatically away from that)
>> >>
>> >> When I first read the post, my thought was: wow, what a convoluted and
>> >> abstruse way of saying "we want to abandon Pagure". Probably this
>> >> wasn't your intent, but that's what I got. And given the reactions,
>> >> other people too.
>> >
>> > The linked blog to the ODF is very explicit that Pagure is one of the 3 
>> > forge options we are considering. I can't stress enough that it's a viable 
>> > choice and ultimately what we opt for will come down to an analysis driven 
>> > by the requirements gathered. I'm unsure how the blog has been interpreted 
>> > any other way but hopefully this clears it up.
>>
>> The ODF is very explicit in the problem statement, and it specifically
>> and clearly says that:
>>
>> 1. Pagure does not align with CPE.
>
> Correct and it's why we said this line, which you might have missed:
> "While we can make exceptions to the mission statement, we first need to know 
> why we should consider a specific exception."

I didn't miss it, I was obviously cherry-picking, but the point was to
argue why this thread "meandered dramatically away from" the initial
purpose: if that was my initial feeling at first reading, probably
that was the case for others.

> CPE has not committed a team to it in over a year, we do state that as a 
> driving factor to why we want to engage in this conversation but your 
> assumption here is based on a particular outcome that sees Pagure not chosen. 
> If Pagure is chosen, we will commit a team. We are very clear on that.

It wasn't so clear to me, but good to know.

> Tell me what you do and how you interact with a forge? That's the point of 
> this exercise.

Those with the most complex workflows would provide most value here. I
only maintain a few simple packages at src.fp, and most of my work is
in Copr.

However, I would say that integration with FAS should be a
requirement. Owning the development of the specific tool (whether a
forge or not) is not a must, in principle, but it's a good thing IMO.
Please correct me if I'm wrong, but that was one of the drivers e.g.
to develop Copr instead of going for OBS.

Iñaki
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 16:18, Julen Landa Alustiza 
wrote:

>
>
> 2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna <
> cve...@fedoraproject.org>-(e)k hau idatzi zuen:
> >On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
> >
> >wrote:
> >
> >> (snip)
> >>
> >> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> >> > To me that's the all point of this
> >> > process, let's put down what we *really* *really* need and  then
> >look at
> >> > the different options.
> >> >
> >>
> >> Do we *really* *really* need to compete with other full featured git
> >> forges on features? The ODF says that this is one of the problem.
> >Well,
> >> imo we don't *really* *really* need to compete with them.
> >>
> >
> >It depends on the use case, doing development work projects hosted on
> >pagure.io is not great in my opinion. In particular working with pull
> >requests.
> >
> I don't have excesive problems with pagure on PR workflows. Right now for
> me centos-ci is a much bigger problem for PR workflows on pagure.io than
> pagure itself for example.
>

Things that I would in my opinion improve Pagure PRs :

* In the PR diff should start from the correct line number, not always 1. (
https://pagure.io/pagure/issue/724)
* Every time a branch is forced pushed you loose the comments from the diff
view. (somewhat related to https://pagure.io/pagure/issue/751)
* It should be possible to display a few lines of code before or after the
diff to help having more context when making the review

Things that would be really nice to have
* Have a way to suggest changes directly while reviewing PRs

Some unrelated to PRs improvement:

* Being able to rename, move projects
* Being able to move a ticket between projects (
https://pagure.io/pagure/issue/737)
* Full Text search projects, users, groups
* Code search (https://pagure.io/pagure/issue/539)
* Support GPG signing commit (https://pagure.io/pagure/issue/751)
* Be able to select which event you want to send on the webhook, ie
everything or nothing

A lot of these a not necessary things we *really* *really* need to have,
but they would make using Pagure much better in my opinion.

>
> >In terms of issue trackers, it is missing the ability to visualize
> >issues
> >in a board for example.
> >Again this my opinion and maybe these are maybe not *really* *really*
> >needed.
>
> Is a great forge the beste solution for this? Or are there other solutions
> for issue tracking/kanban/boards etc that could better suit this use cases?
>

Possibly but having the feature available at least gives you one more
option.


> >
> >
> >> Actually we already have the features that we *really* *really* need.
> >> Otherwise we could not release fedora using pagure as we are using,
> >> could we? :)
> >>
> >
> >I personally don't think we can release Fedora without people across
> >the
> >project doing heroics and a crazy amount of hours which seems to have
> >become a norm rather than an exception.
> >
> +1. But is this a git forge problem?
>
> We are again on the same place: we have different use cases hosted on
> pagure. Some of them could need a big effort on pagure side to compete with
> other options (on technical features), some others could benefit of
> migrating to other solutions, and some others could not have a better
> solution than our own custom one
>
> --
> Julen Landa Alustiza 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Stephen John Smoogen]

On Wed, 29 Jan 2020 at 11:38, Clement Verna  wrote:
>
>
>
> On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon  wrote:
>>

>> these heroics related to pagure?
>>
>> If not, I'm not sure what is the point you were trying to make for this 
>> thread.
>
>
> My point is that we have to dedicate a team to work on Pagure, I would rather 
> have these people working on improving the infrastructure so that we don't 
> need these heroics to happen. If we don't put people to work on Pagure it 
> will end up being another fedora-packages, badges or FAS and in couple years 
> it will be too difficult to do anything with it. It is not only about Pagure, 
> for example I would love to be able to replace Bodhi with something that we 
> don't have to maintain but it is much more difficult to find an alternative 
> to Bodhi than Pagure.
>

We would instead need a dedicated team to work on integrating all our
tools with some other dist-git. Either using the people who are
already working on pagure, or some new set of people who have to be
hired in with a background in how-ever Git*** works. There will still
always be some group having to deal with how and what we do with our
source code. All we are doing is changing it from something we have
more control to direct to something we constantly adapt to its
changes. In other words, the heroics just change because we have
worked on a symptom for the cause of the heroics.. not the root cause
of the heroics.


> My general feeling is that an infrastructure team should avoid as much as 
> possible to maintain large applications, the focus should be to develop the 
> glue needed to for the different services to work together in the most 
> efficient manner, to monitor the applications, the respond to outages.

The issue is that we are not going to see less work here and so there
is not going to be less heroics. Some group is going to have to make
tooling changes to make fedpkg, bodhi, koji, pdc, authentication etc
etc work with Git*** and keep up with every API change that occurs
over the years there. Some group is going to have to engineer new
caching layers to deal with source code in XYZ area and builders in
ABC area. Some group is going to have to add in all the documentation
and rules for dealing with any outage/burp/authentication Git***.

This doesn't mean that work should not be done.. but do not try to
sell it that it will drop the need for heroics and long hours. That
needs different changes and have nothing to do whether we have our
source code in Pagure or Gitlab. It has nothing to do with whether we
use OBS or Koji. It has to do with things much more fundamental about
what we are supposed to be doing, what we are supposed to not be
doing, and how much we are supposed to do towards either set. Trying
to lop off things one by one while we are adding in things 2x2 doesn't
help.



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 16:56, Adam Williamson 
wrote:

> On Wed, 2020-01-29 at 15:56 +0100, Clement Verna wrote:
> > On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza <
> jla...@fedoraproject.org>
> > wrote:
> >
> > > (snip)
> > >
> > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > > > To me that's the all point of this
> > > > process, let's put down what we *really* *really* need and  then
> look at
> > > > the different options.
> > > >
> > >
> > > Do we *really* *really* need to compete with other full featured git
> > > forges on features? The ODF says that this is one of the problem. Well,
> > > imo we don't *really* *really* need to compete with them.
> > >
> >
> > It depends on the use case, doing development work projects hosted on
> > pagure.io is not great in my opinion. In particular working with pull
> > requests.
>
> > In terms of issue trackers, it is missing the ability to visualize issues
> > in a board for example.
> > Again this my opinion and maybe these are maybe not *really* *really*
> > needed.
>
> I think it depends on the size and scope of your project a bit. I do
> find Pagure.io a pretty good host of the projects I have there, as
> they're fairly small. But then, an open source (non-enterprise edition)
> Gitlab instance would work fine for them too.
>

Yes I agree with you, Pagure does a good job with small size project. It is
also easy deploy and self host. And as I mentioned earlier in this thread
my main real complain with Pagure is that we have to invest time to develop
it and maintain it. I would be very happy to use it, if it was developed
and maintained by someone else :-)


>
> >
> > > Actually we already have the features that we *really* *really* need.
> > > Otherwise we could not release fedora using pagure as we are using,
> > > could we? :)
> > >
> >
> > I personally don't think we can release Fedora without people across the
> > project doing heroics and a crazy amount of hours which seems to have
> > become a norm rather than an exception.
>
> When that happens it doesn't normally involve Pagure much, though. And
> I don't think even an amazing git forge would actually go a long way to
> solving the main issues there.
>

It is not about the git forge itself it is about how and on what we spend
the little resources we have. If as a community we are all happy to invest
this time on developing and maintaining a git forge that's all fine with
me. But as said earlier we have not invested much in Pagure for more than a
year, that allowed us to put a lot of effort and focus on Bodhi to add
support for rawhide including people being able to use side-tag in rawhide
now. Should we continue like that and feature freeze Pagure ? or do we
invest in Pagure instead of other work that need to be done ? Do we switch
to another forge, knowing that it will require a LOT of initial effort to
migrate ? I honestly don't know what is the correct answer :-)



> --
> 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
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Robbie Harwood]

Julen Landa Alustiza  writes:

> (snip)
>
> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>> To me that's the all point of this 
>> process, let's put down what we *really* *really* need and  then look at 
>> the different options.
>> 
>
> Do we *really* *really* need to compete with other full featured git 
> forges on features? The ODF says that this is one of the problem. Well, 
> imo we don't *really* *really* need to compete with them.
>
> Actually we already have the features that we *really* *really* need. 
> Otherwise we could not release fedora using pagure as we are using, 
> could we? :)

We don't have per-branch default assignees, which is actually a pretty
big problem in Fedora (especially with EPEL packages).

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 18:26, Stephen John Smoogen  wrote:

> On Wed, 29 Jan 2020 at 11:38, Clement Verna 
> wrote:
> >
> >
> >
> > On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon 
> wrote:
> >>
>
> >> these heroics related to pagure?
> >>
> >> If not, I'm not sure what is the point you were trying to make for this
> thread.
> >
> >
> > My point is that we have to dedicate a team to work on Pagure, I would
> rather have these people working on improving the infrastructure so that we
> don't need these heroics to happen. If we don't put people to work on
> Pagure it will end up being another fedora-packages, badges or FAS and in
> couple years it will be too difficult to do anything with it. It is not
> only about Pagure, for example I would love to be able to replace Bodhi
> with something that we don't have to maintain but it is much more difficult
> to find an alternative to Bodhi than Pagure.
> >
>
> We would instead need a dedicated team to work on integrating all our
> tools with some other dist-git. Either using the people who are
> already working on pagure, or some new set of people who have to be
> hired in with a background in how-ever Git*** works. There will still
> always be some group having to deal with how and what we do with our
> source code. All we are doing is changing it from something we have
> more control to direct to something we constantly adapt to its
> changes. In other words, the heroics just change because we have
> worked on a symptom for the cause of the heroics.. not the root cause
> of the heroics.
>

I completely agree that changing solution would be a massive effort and I
honestly don't know if it is worth it or not. In my opinion the root cause
of the heroics is that we keep adding and building new things on top of
foundation that is not stable. One of the reason for this foundation not
been stable is that we have too much to do, so we cut corners (the famous
quick fixes which becomes a permanent hack that everyone is scared to
touch). We cannot win this battle without reducing the number of things we
have to care for. Maybe I am too naive but for me the only way to reduce
these heroics is first to reduce the number of applications we have, second
take the time it takes to reduce the technical debt we have.

You have way more history and knowledge than me, so I am genuinely
interested to know what are the root cause for you ? And what would it take
to improve the situation ?


>
> > My general feeling is that an infrastructure team should avoid as much
> as possible to maintain large applications, the focus should be to develop
> the glue needed to for the different services to work together in the most
> efficient manner, to monitor the applications, the respond to outages.
>
> The issue is that we are not going to see less work here and so there
> is not going to be less heroics. Some group is going to have to make
> tooling changes to make fedpkg, bodhi, koji, pdc, authentication etc
> etc work with Git*** and keep up with every API change that occurs
> over the years there.


This assumes that Pagure will never break its API compatibility and that we
will never have to update all the different tools in that case. For me the
effort is the same here maybe even less for Git*** since we would most
likely use an library wrapping the API which could deal with the backward
compatibility.


> Some group is going to have to engineer new
> caching layers to deal with source code in XYZ area and builders in
> ABC area. Some group is going to have to add in all the documentation
> and rules for dealing with any outage/burp/authentication Git***.
>
> This doesn't mean that work should not be done.. but do not try to
> sell it that it will drop the need for heroics and long hours. That
> needs different changes and have nothing to do whether we have our
> source code in Pagure or Gitlab. It has nothing to do with whether we
> use OBS or Koji. It has to do with things much more fundamental about
> what we are supposed to be doing, what we are supposed to not be
> doing, and how much we are supposed to do towards either set. Trying
> to lop off things one by one while we are adding in things 2x2 doesn't
> help.
>

I agree that this will probably not make a huge difference, but I am an
optimistic and I prefer to take one tiny step in one direction without
knowing if it will make a difference rather than stay still waiting for
selling to fall on my head. "When eating an elephant, take one bite at a
time.” - Creighton Abrams

What are the different changes needed to avoid heroics ? What stops us from
making these ?


>
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List 

Re: Ideas for better development processes when maintaining hundreds of packages

[Ken Dreyer]

On Wed, Jan 29, 2020 at 7:18 AM Remi Collet  wrote:

> There are different:
>
> * Changelog is for end user
> * Git log is for package maintainer

I completely agree with this distinction. We're creating more "noise"
for end users if we end up adding all the "whoops" commits into the
%changelog. And asking maintainers to add "[skip]" strings or whatever
into the Git commit logs adds yet another magic/manual thing that
packagers must learn.

This is why rdopkg writes the dist-git commit messages from the RPM
%changelog instead of the other way around. For example I can write or
modify my message in %changelog, run "rdopkg amend", and it
automatically updates my dist-git message to match what I wrote in
%changelog. I have not had to copy-and-paste information from
%changelog into the dist-git message in years.

> > * committing to git should build the package
> >
> > Is there a reason why this wouldn't be the case?
>
> Yes, because I often commit various changse "before" the build
> (some being cherry-pick on other branch, some not)

This one I happen to disagree with. I've set up a Jenkins job that
automatically builds on another (non-Fedora) Koji instance for a large
number of packages, and it is fantastic to never worry about
remembering to run "rpkg build" by hand any more. I trigger the builds
on the "push" bus messages though, instead of building every single
commit. If I'm making many small changes, then I'll commit them all to
Git locally, then push them all at once. When other developers don't
follow that practice of batching up their commit pushes, it does mean
that Koji ends up building a lot more frequently, and we trigger
composes more frequently throughout each day... but frankly that leads
to some other advantages, because it makes things more "continuous"
overall.

> IMHO, remember KISS, and don't try to add more magic to our tooling
>
> And I really prefer to see stabilization of our current tools and
> infrastructure before breaking it again.

I completely agree with this Remi. We're still suffering from the loss
of pkgdb's features. I would prefer to fix what's broken before trying
to mess with changelogs and end up with something half-baked.

- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to handle circular build dependencies?

[Markku Korkeala]

Richard W.M. Jones kirjoitti 27.1.2020 22:35:

On Mon, Jan 27, 2020 at 06:43:36PM +0200, Markku Korkeala wrote:
I think it's Perl where IIRC the package can be configured
as a bootstrap package (by setting an RPM variable), built
that way, the dependencies are then built, then the perl
package is flipped back to non-bootstrap mode and built a
second time against those just built dependencies.

If you do it all in a side tag then no one will see the
intermediate packages.


I know I can update clojure to certain alpha version,
which the new libraries require. Then build those,
and when they are accepted then upgrade the
clojure package, and then upgrade those libraries, etc. But
it is tedious. I'm hoping there would be a better
way :)


Is it possible to build a "cut down" clojure which
doesn't need the dependencies (ie that would be the
bootstrap version)?


And also do I have to do that bootstrapping
again when building clojure for example EPEL-8?


Probably :-)

IMHO it helps to script Koji builds.  We don't have any official
tooling for that as far as I'm aware, but various people have built
unofficial tools including me (see
https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/
http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary)

Rich.


Hi,

thanks for all the suggestions and links. It should be possible to
build "cut down" clojure, but might require too much effort. I think
I'll study the problem little bit more and see also how the Debian
maintainers solved this issue.

--
Markku
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to handle circular build dependencies?

[Markku Korkeala]

Rex Dieter kirjoitti 28.1.2020 16:57:

Markku Korkeala wrote:


Hi,

sorry if this a newbie question, I tried to search this
but did not find good documentation on this problem.

I'm in the process of upgrading the clojure package to
next version, which has new dependencies. These dependencies
require certain clojure version themselves, so it makes a
chicken-and-egg kind of problem. Are there good ways to handle
these kind of circular dependencies?


See if this helps,
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping


Hi,

thanks, I'll check that out.

Markku.


-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Review swaps - practrand - Software package for the Randon number generation & testing

[Ankur Sinha]

On Wed, Jan 29, 2020 01:18:48 +0100, Jiri Hladky wrote:
> Hi,

Hi Jirka,

> I have a simple package for review. It's called practrand - a Software package
> for the Randon number generation & testing
> https://bugzilla.redhat.com/show_bug.cgi?id=1795461

I see that it hasn't been taken up for review yet, so I can do it.

> I offer to review some simple package in return. 

I have nothing that needs review at the moment, so that's OK :)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Miro Hrončok]

Hello, Fedora has an approved security policy since September 2018 [0]:


If a CRITICAL or IMPORTANT security issue is currently open
against a package, or a security issue of lower severity has been
open for at least 6 months, four weeks before the branch point a
procedure similar to long-standing FTBFS will be triggered
immediately, with 8 weeks of weekly notifications to maintainers and
subsequent orphaning and then subsequent removal from distribution.
This applies to all packages, not just leaf.


I have decided to have a look into this, since this has been approved more than 
a year ago and nothing ever happened since. Fedora has a very big pile of open 
CVE bugzillas [2].


There are several things I'd like us to consider based on the experience from 
the FTBFS policy adjustments [1] before I go implement stuff:



A. It's easier to **orphan** packages soon, retire later -- this allows the 
dependent package owners  to notice the breakage and possibly adopt the packages 
themselves if needed while gives very little room for "cheating".


B. Getting this done on a certain point in the release schedule is complicated 
and requires a lot of  planning and focus -- if we miss the window, nothing can 
change until the next release. We have missed the window 3 times already.


C. Also because of the fixed date, the CRITICAL or IMPORTANT security issues 
have no response time, if you get a new one at a certain point, the package is 
immediately treated as problematic, while getting it 1 day later, there is a 6 
month period where no action is required.



I'd like to adjust the policy before I go implement some tooling around this.

This is vague proposal of what I think would work easier for both "the 
executioner" and the affected maintainers:



1. We automatically send reminders to NEW security bugzillas (as with FTBFS)
2. BZs that remain in NEW state for X reminders: pkg is orphaned
3. BZs that remain not CLOSED for Y months: pkg is retired (with notifications)


Point 2 makes it so that only a couple remaining packages actually need to 
survive unfixed to point 3. Hence, point 3 can happen at a certain point in the 
schedule with less severe impact of points B and C -- and if we miss the window, 
we still have point 1 happening.



The bugzilla reminders are sent every third calendar week (every week is too 
disturbing).



Here is an initial (albeit randomly generated) proposal of X and Y:

severity   CRITICAL/HIGH MEDIUM  LOW
X 2 4 6
Y 2 4 6

Note that X=1 effectively means anything from 1 second to 3 weeks, X=2 means 
anything from 3 weeks (+1 second) to 6 weeks. Hence, we cannot orphan packages 
after just 1 reminder.


I've made it so that X always equals to Y and every lower level is +2, to make 
it easier to document, understand and remember, however this is not required.



For this example a critical/high CVE would get a reminder every third calendar 
week. After two reminders (that is after 3-6 weeks), if still in NEW state, 
package is orphaned. The maintainer (and others) still have extra 6 weeks to 
claim it.
If the bug is ASSIGNED, MODIFIED, etc., the package may be retired after 2 
months, but that only happens regularly at a certain point in the schedule.


Similarly, a package with a medium CVE NEW bugzilla would be orphaned after 4 
reminders (after 9-12 weeks), retired at a point if still not CLOSED after 4 months.


With low severity, that is 6 reminders (after 15-18 weeks), retired at a point 
if still not CLOSED after 6 months (similarly to the current policy).



Please share your feedback, before I proceed with this to FESCo.
If somebody would be interested in maintaining this procedure, I'd be happy to 
hand over that responsibility to anybody who is willing to help.
The idea is to start with semi-automation and have something -- currently we had 
hoped for fully automated and we have nothing.



[0] https://pagure.io/fesco/issue/1935
[1] https://pagure.io/fesco/issue/2244
[2] https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Richard W.M. Jones]

On Wed, Jan 29, 2020 at 10:26:56PM +0100, Miro Hrončok wrote:
> Here is an initial (albeit randomly generated) proposal of X and Y:
> 
> severity   CRITICAL/HIGH MEDIUM  LOW
> X 2 4 6
> Y 2 4 6

In RHEL, low impact security bugs wouldn't normally be fixed until the
next minor release, which would be 6-12 months after the issue is
reported.  I don't think it's valuable to badger packagers about bugs
that have "minimal consequences" to use the terminology from

https://access.redhat.com/security/updates/classification

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Miro Hrončok]

On 29. 01. 20 22:49, Richard W.M. Jones wrote:

On Wed, Jan 29, 2020 at 10:26:56PM +0100, Miro Hrončok wrote:

Here is an initial (albeit randomly generated) proposal of X and Y:

severity   CRITICAL/HIGH MEDIUM  LOW
 X 2 4 6
 Y 2 4 6


In RHEL, low impact security bugs wouldn't normally be fixed until the
next minor release, which would be 6-12 months after the issue is
reported.  I don't think it's valuable to badger packagers about bugs
that have "minimal consequences" to use the terminology from

https://access.redhat.com/security/updates/classification



My idea was that within half a year, it should be wither fixed or CLOSED as 
WONTFIX or UPSTREAM. If we don't agree, I'm completely fine making it 12 months 
or even ignore such bugs in the policy entirely.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Wed, Jan 29, 2020, 17:19 Iñaki Ucar  wrote:

> On Wed, 29 Jan 2020 at 16:23, Leigh Griffin  wrote:
> >
> > On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar 
> wrote:
> >>
> >> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin 
> wrote:
> >> >
> >> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar 
> wrote:
> >> >>
> >> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin 
> wrote:
> >> >> >
> >> >> > This thread is serving as a source of requirements (although it
> has meandered dramatically away from that)
> >> >>
> >> >> When I first read the post, my thought was: wow, what a convoluted
> and
> >> >> abstruse way of saying "we want to abandon Pagure". Probably this
> >> >> wasn't your intent, but that's what I got. And given the reactions,
> >> >> other people too.
> >> >
> >> > The linked blog to the ODF is very explicit that Pagure is one of the
> 3 forge options we are considering. I can't stress enough that it's a
> viable choice and ultimately what we opt for will come down to an analysis
> driven by the requirements gathered. I'm unsure how the blog has been
> interpreted any other way but hopefully this clears it up.
> >>
> >> The ODF is very explicit in the problem statement, and it specifically
> >> and clearly says that:
> >>
> >> 1. Pagure does not align with CPE.
> >
> > Correct and it's why we said this line, which you might have missed:
> > "While we can make exceptions to the mission statement, we first need to
> know why we should consider a specific exception."
>
> I didn't miss it, I was obviously cherry-picking


It gives a very different view when considered in balance Vs a selective
quote. That's why I replied on the off chance someone is driving by the
thread and skips the key points in the post.

, but the point was to
> argue why this thread "meandered dramatically away from" the initial
> purpose: if that was my initial feeling at first reading, probably
> that was the case for others.


> > CPE has not committed a team to it in over a year, we do state that as a
> driving factor to why we want to engage in this conversation but your
> assumption here is based on a particular outcome that sees Pagure not
> chosen. If Pagure is chosen, we will commit a team. We are very clear on
> that.
>
> It wasn't so clear to me, but good to know.
>

Glad I could clarify it, I'm happy to update the original ODF document if
it makes it clearer for others.

>
> > Tell me what you do and how you interact with a forge? That's the point
> of this exercise.
>
> Those with the most complex workflows would provide most value here. I
> only maintain a few simple packages at src.fp, and most of my work is
> in Copr.
>

I suspect that a bulk of our users are similar to you. Given that you are
engaged on the thread (thank you!) what is your day to day needs? What
features are part of your usage and interaction? What's missing or what
would you like to see added? Your voice here can help represent that group
and is most welcome.


> However, I would say that integration with FAS should be a
> requirement. Owning the development of the specific tool (whether a
> forge or not) is not a must, in principle, but it's a good thing IMO.
> Please correct me if I'm wrong, but that was one of the drivers e.g.
> to develop Copr instead of going for OBS.
>
> Iñaki
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 12:52:53PM -0500, Robbie Harwood wrote:
> Julen Landa Alustiza  writes:
> 
> > (snip)
> >
> > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> >> To me that's the all point of this 
> >> process, let's put down what we *really* *really* need and  then look at 
> >> the different options.
> >> 
> >
> > Do we *really* *really* need to compete with other full featured git 
> > forges on features? The ODF says that this is one of the problem. Well, 
> > imo we don't *really* *really* need to compete with them.
> >
> > Actually we already have the features that we *really* *really* need. 
> > Otherwise we could not release fedora using pagure as we are using, 
> > could we? :)
> 
> We don't have per-branch default assignees, which is actually a pretty
> big problem in Fedora (especially with EPEL packages).

I'd counter-argue that we don't need one considering bugzilla doesn't support a
per-version assignee. So we need an assignee for Fedora and one for Fedora
EPEL, going the level lower (F31, F30, F29, epel8, epel7...) does not bring
anything since we wouldn't be able to sync this to bugzilla.

And the Fedora vs Fedora EPEL overrides/assignee is being worked on so we can
move it off fedscm-requests where it is today to src.fp.o.


Pierre


pgp7ggPJoZWO2.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [security] only latest Qt 5.14.1 has all fixes

[Damian Ivanov]

Hello Rex,

>So, we (kde-sign, Qt maintainers) generally update strategically where it
>makes sense to warrant the time investment in doing so.

I understand.
Also that some people contribute it in their free time/or paid time
(but not mandatory to contribute),
which of course means a lot.

I understand that packaging is a fairly time consuming task.
Back in the days when I used openSUSE and OBS I built the Unity
desktop environment
and maintained it a release and a half IIRC (30+ packages where some
require custom vendor patches),
different from what the distribution (gnome, the patches) uses.
Another contributor chenxialong packaged it at that time for Fedora on OBS
from the same repository (because doing something more sophisticated
than (cross) build a simple package
is not possible using Fedora tools, but todays requirements are) so a
lot of the packaging effort was shared.

As (re)build takes some time it is nice to edit some things (spec
files) from the web interface,
on your phone from the gym or on another computer very easily possible
in OBS. I think that
something similar would attract people to contribute to the packaging
in Fedora in general.

>Bumping Qt versions is... a fairly difficult process in fedora,
>unfortunately.

I understand, but there are some things that concern me.
I would like to use secure Qt (5.14) with all security critical fixes
(and new functions) built for Fedora.
As a User of Fedora I would like to contribute and others to
contribute as a packager but
I do not see tools that provide the minimum requirements to do so.
(a Web Interface for spec file editing, multiple repos e.g for Qt).
As a Linux enthusiast I am deeply concerned with a far better (and
long term easier to maintain)
technical solution being suppressed either by incapable management, "I
just work there" mentality
or people who prefer to spend hours of work they are used too instead
of 5 minutes work that's new for them
(reminds me of systemd somehow).

>Bumping Qt versions is... a fairly difficult process in fedora,
>unfortunately.

Introducing a new Qt version could be very simple I think:
1) Branch all Qt related packages (it should be with a one line
command or using a web interface)
2) Edit package version number (with a per project (like Qt:5.14.1
project) macro - 1 digit changed/or two)
3) Wait for packages to be published into repo (and that repo contains
all packages - without spec change - that use Qt priv headers).
4) Fix eventual build failures due to re based patches etc.
5) optional: Press push to start a request to get this merged into main repo.

>Bumping Qt versions is... a fairly difficult process in fedora,
>unfortunately.
Would a workflow similar to the one described allow speed up providing
the newest Qt optionally in let's say
qt5.14/x86_64/{rawhide, f32, f31. f30} but keeping the main repo
unchanged if desired?
Would you say that the current build system maybe needs improving or a
rework to provide kde-sign, Qt maintainers and you
you with a slightly less difficult process?
Would you agree that having the possibility for users to choose a
different Qt version from a different versioned repo
may help testing and improve quality?
Would you and the kde-sign, Qt maintainers say that the workflow
described above maybe is exactly what is needed (OBS)?

Br,
Damian



On Wed, Jan 29, 2020 at 6:32 PM Rex Dieter  wrote:
>
> Damian Ivanov wrote:
>
> > But it's not the only CVE fixed with Qt 5.14.1
> > The point is that there is other software using Qt which doesn't start
> > with K even though K works just fine with 5.14 by the experience of other
> > distributions.
>
> Bumping Qt versions is... a fairly difficult process in fedora,
> unfortunately.  The primary reason is that there are many packages that use
> Qt private api's the require rebuilding for every release.  Quick check just
> now in rawhide is that a full Qt5 version update requires (re)building at
> least 78 packages.
>
> So, we (kde-sign, Qt maintainers) generally update strategically where it
> makes sense to warrant the time investment in doing so.
>
> -- Rex
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas for better development processes when maintaining hundreds of packages

[Dan Čermák]

Pierre-Yves Chibon  writes:

> On Tue, Jan 28, 2020 at 11:51:29PM +0100, Dan Čermák wrote:
>> "Richard W.M. Jones"  writes:
>> 
>> > I always think that Fedora works fine if you maintain 1-5 packages.
>> > It's possible to maintain 20 with a lot of work.  And if you want to
>> > maintain 100+ (things like the ocaml-* set that I help to maintain)
>> > then you have to write your own automation.  Could we do things
>> > better?  No one asked for them, but here are my ideas ...
>> >
>> > ---
>> >
>> > * kill the %changelog
>> >
>> > Please, let's kill it, and generate it from the git changelog.
>> > I'm glad to see there's a proposal to do this.
>> >
>> > A general principle I'm following here is a packager should never
>> > be asked to enter the same information twice.
>> >
>> > * committing to git should build the package
>> >
>> > Is there a reason why this wouldn't be the case?
>> 
>> Not really no. I've been involved quite a bit in building packages on
>> openSUSE's Buildservice and every commit there results in a rebuild. So it
>> is doable, *but* OBS has the advantage that it discards all builds
>> except for the most recent successful one, or it would have run out of
>> storage ages ago.
>> 
>> Although someone (Randy Barlow maybe?) had the idea to generate the
>> changelog and to trigger builds from git tags instead of commits, which
>> has a certain charm to it as well. If there was a choice whether to
>> trigger builds from commits or tags and how to generate the %changelog,
>> then I think that most use cases should be covered?
>
> The original idea of using git tag is Jeremy Cline's.
> If we support: automatically building from commit or not, then I don't think 
> we
> need to support building from git tag, using the current approach would work
> just as well when you don't want to build from commit.

Building from a git tag would have the advantage, that each build would
show up on pagure under the "Releases" tab, albeit that is probably just
a cosmetic advantage.

>
>> > * commit groups of packages together
>> >
>> > One reason why automatic commit -> build might not be desirable is if
>> > you're trying to build a group of packages in a side tag.  In my
>> > opinion this means we should allow groups of packages to be committed
>> > together.  (Unfortunately because we chose to put every package in its
>> > own git repo, the obvious way to do this can't work, but we could
>> > still have a "ChangeId:" header in the commit message that ties
>> > packages together).
>> >
>> > The packages should be built in build dependency order into a side
>> > tag, and the side tag turned into an update, with no further
>> > involvement from the packager unless something fails to build.
>> >
>> > This change on its own would solve the main problem that
>> > affects people maintaining large sets of packages.
>> 
>> How about something like `fedpkg add-to-side-tag` (yes the name needs
>> work) that would work like this:
>> 
>> $ fedpkg request-side-tag
>> $ fedpkg add-to-side-tag $tag_name $pkgA $pkgB $pkgC $pkgGlob
>> 
>> Now all git commits/tags pushed to $pkgA $pkgB $pkgC $pkgGlob result in
>> them being built in the side tag $tag_name by default. Once the side tag
>> is merged, you go back to building the "ordinary way".
>
> Isn't that just fedpkg chain-build --target=$tag_name ... ?

Could be, I've never used it.

> This is already existing and working, however, it requires the different
> packages are up to date in git (ie: you've made and push the commit updating 
> the
> spec file to the next release/version) which goes against the point above 
> about
> automatically build on commit.

Well, my idea was that you tell the infra: "hey, from this point onward
(until the side tag is merged or I turn it off), I want every commit to
be built in the side tag".


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Kevin Kofler]

Miro Hrončok wrote:
> My idea was that within half a year, it should be wither fixed or CLOSED
> as WONTFIX or UPSTREAM. If we don't agree, I'm completely fine making it
> 12 months or even ignore such bugs in the policy entirely.

I don't see how it is an improvement to close security fixes that are 
blocking on upstream (in)action as UPSTREAM, as opposed to keeping them open 
so that it is clear to everyone that they need to be fixed.

I think that the policy being discussed here just ought to be dropped 
entirely, because it will do absolutely nothing to make Fedora actually more 
secure, but only amounts to extra bureaucracy and extra work for packagers.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Huzaifa Sidhpurwala]

On 1/30/20 8:32 AM, Kevin Kofler wrote:
> Miro Hrončok wrote:
>> My idea was that within half a year, it should be wither fixed or CLOSED
>> as WONTFIX or UPSTREAM. If we don't agree, I'm completely fine making it
>> 12 months or even ignore such bugs in the policy entirely.
> 
> I don't see how it is an improvement to close security fixes that are 
> blocking on upstream (in)action as UPSTREAM, as opposed to keeping them open 
> so that it is clear to everyone that they need to be fixed.
> 
Issues which are blocking on upstream, will eventually get resolved once
upstream figures out a solution in some time, maybe with subsequent rebases.
> I think that the policy being discussed here just ought to be dropped 
> entirely, because it will do absolutely nothing to make Fedora actually more 
> secure, but only amounts to extra bureaucracy and extra work for packagers.
If fixing security issues is extra work for packagers, then we are doing
something wrong here. What percentage of security flaws will be
closed:upstream? Why do we drop other fixes for such issues and
eventually end up having tons of pending fixes.

Do we want to continue the same condition as described here:
https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/




> 
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 


-- 
Huzaifa Sidhpurwala / Red Hat Product Security
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Huzaifa Sidhpurwala]

On 1/30/20 3:19 AM, Richard W.M. Jones wrote:
> On Wed, Jan 29, 2020 at 10:26:56PM +0100, Miro Hrončok wrote:
>> Here is an initial (albeit randomly generated) proposal of X and Y:
>>
>> severity   CRITICAL/HIGH MEDIUM  LOW
>> X 2 4 6
>> Y 2 4 6
> 
> In RHEL, low impact security bugs wouldn't normally be fixed until the
> next minor release, which would be 6-12 months after the issue is
> reported.  I don't think it's valuable to badger packagers about bugs
> that have "minimal consequences" to use the terminology from
> 
> https://access.redhat.com/security/updates/classification

There are various reasons why lows are not fixed immediately in RHEL,
including the fact that customers dont like too many updates because of
production systems downtime. Not all of them may be applicable for
fedora users.

The above being said, i am ok with deferring lows, but please lets fix
or close others?
> 
> Rich.
> 


-- 
Huzaifa Sidhpurwala / Red Hat Product Security
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

review swap , nodejs packages need some updates

[Sérgio Basto]

Hi, 

I took  js-jquery-file-upload package to save js-query , I updated [1]
but we still need update nodejs-multimatch [2], nodejs-p-limit [3] and
nodejs-lodash [4] at least !

To update nodejs-p-limit, we need nodejs-p-try which isn't in Fedora,
here is the package review request [5]



[1] 
rpms/nodejs-dateformat
rpms/nodejs-find-up
rpms/nodejs-load-grunt-tasks
rpms/nodejs-locate-path
rpms/nodejs-pkg-up
rpms/nodejs-p-locate 

[2]
https://bugzilla.redhat.com/show_bug.cgi?id=1531018
[3]
https://bugzilla.redhat.com/show_bug.cgi?id=1701835
[4]
https://bugzilla.redhat.com/show_bug.cgi?id=1297999
[5]
https://bugzilla.redhat.com/show_bug.cgi?id=1796268


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Chown checkstyle, checkstyle-maven-plugin, google-http-java-client

[Bill Chatfield via devel]

According the procedure for retired packages, I'm announcing my intention to 
take ownership of checkstyle, checkstyle-maven-plugin, and 
google-http-java-client. They are all retired as far as I can tell.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Chown checkstyle, checkstyle-maven-plugin, google-http-java-client

[Felix Schwarz]

Hi Bill,

Am 30.01.20 um 07:25 schrieb Bill Chatfield via devel:
> According the procedure for retired packages, I'm announcing my intention to
> take ownership of checkstyle, checkstyle-maven-plugin, and
> google-http-java-client. They are all retired as far as I can tell.

Welcome to Fedora - I'm glad you are working to improve Fedora's Java
packaging :-)

Packages which are retired for more than 8 weeks need a new review request
(basically just like a new package):
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

You could send links to your review requests to this mailing list - I guess
this will increase the chance of a quick review.

Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org