What is IMHO crucial is the understanding that the part of Fedora
infrastructure facing maintainers *needs* to respect the fact that
each (upstream) project is different, has different workflow, version
control system, way to make releases and to ship them, ... . Thus
Fedora must allow different ap
Dne 11. 10. 19 v 23:34 Adam Williamson napsal(a):
> On Fri, 2019-10-11 at 17:10 -0400, Randy Barlow wrote:
>> On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
>>> No. Resolving conflicts implies that you need to do an actual merge,
>>> NOT a
>>> fast forward. Fast-forwarding means that I am
On Sat, Oct 12, 2019 at 11:35 PM Kevin Kofler wrote:
>
> Randy Barlow wrote:
> > Why have branches at all if you are going to have the file be the same
> > in all branches?
>
> Because the policies require them, and the tooling (fedpkg) is designed for
> them.
>
If I could, I'd drop branches for
Randy Barlow wrote:
> Why have branches at all if you are going to have the file be the same
> in all branches?
Because the policies require them, and the tooling (fedpkg) is designed for
them.
Kevin Kofler
___
devel mailing list -- devel@lists
Randy Barlow wrote:
> On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
>> No. Resolving conflicts implies that you need to do an actual merge,
>> NOT a fast forward. Fast-forwarding means that I am shipping the SAME
>> commit on all branches, so the changelog must be identical (unless I play
On Thu, 2019-10-03 at 19:02 +, Zbigniew Jędrzejewski-Szmek wrote:
> > As pointed out elsewhere, we would have fewer conflicts if we could
> > get
> > the version, release, and changelog out of the spec file, and then
> > I
> > think maintaining different spec in different release branches
> > w
On Fri, 2019-10-11 at 14:34 -0700, Adam Williamson wrote:
> That seems like a personal call, really. I very much like being able
> to
> keep branches in sync without merge commits as it means I can do
> stuff
> like:
>
> for i in el6 epel7 f29 f30 f31 master; do fedpkg switch-branch $i;
> git
> pu
On Fri, 2019-10-11 at 17:10 -0400, Randy Barlow wrote:
> On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
> > No. Resolving conflicts implies that you need to do an actual merge,
> > NOT a
> > fast forward. Fast-forwarding means that I am shipping the SAME
> > commit on
> > all branches, so
On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
> No. Resolving conflicts implies that you need to do an actual merge,
> NOT a
> fast forward. Fast-forwarding means that I am shipping the SAME
> commit on
> all branches, so the changelog must be identical (unless I play games
> with
> %if
On Thu, 10 Oct 2019 at 20:33, Kevin Kofler wrote:
>
> Matthew Miller wrote:
> > On Thu, Oct 10, 2019 at 12:28:37AM +0200, Kevin Kofler wrote:
> >> The problem does not only happen if the module is a non-leaf at module
> >> level, but there can also be conflicts at package level, if the modules
> >
Matthew Miller wrote:
> On Thu, Oct 10, 2019 at 12:28:37AM +0200, Kevin Kofler wrote:
>> The problem does not only happen if the module is a non-leaf at module
>> level, but there can also be conflicts at package level, if the modules
>> bundle non-leaf packages that then conflict between the 2 mod
On Thu, Oct 10, 2019 at 12:28:37AM +0200, Kevin Kofler wrote:
> > Yeah, I agree that there's a problem with non-parallel-installable modules
> > that aren't effectively leaves.
> The problem does not only happen if the module is a non-leaf at module
> level, but there can also be conflicts at pack
Matthew Miller wrote:
> Yeah, I agree that there's a problem with non-parallel-installable modules
> that aren't effectively leaves.
The problem does not only happen if the module is a non-leaf at module
level, but there can also be conflicts at package level, if the modules
bundle non-leaf pack
Dridi Boukelmoune wrote:
> Modularity should have been opt-in until major bugs are ironed out,
> and maybe we would have realized in time that either it's great or it
> doesn't solve anything the problem it's addressing.
+1
Kevin Kofler
___
deve
On Tue, Oct 08, 2019 at 02:06:06AM +0200, Kevin Kofler wrote:
> Sure, I fully understand the theoretical benefits to be had from Modularity
> (though I still think that this is much more useful for LTS distributions
> such as RHEL or CentOS than for Fedora). The issue is that it all breaks
> dow
On Tue, Oct 8, 2019 at 12:06 AM Kevin Kofler wrote:
>
> Matthew Miller wrote:
> > A key goal of the modularity project is to allow some of the cases to be
> > better addressed by allowing packagers to think in terms of upstream
> > changes which affect user experience separate from the Fedora rele
Matthew Miller wrote:
> A key goal of the modularity project is to allow some of the cases to be
> better addressed by allowing packagers to think in terms of upstream
> changes which affect user experience separate from the Fedora release
> cycle. The default stream for a package shouldn't be upda
On Sat, Oct 05, 2019 at 02:35:59AM +0200, Kevin Kofler wrote:
> There are many possible reasons for shipping the same upstream release
> across different Fedora releases:
[...snip good list of reasons...]
> That said, I am not a fan of the Updates Policy as written because it is
> written in th
On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon wrote:
> So I've been wondering a little bit how we could solve this and I've been
> wondering if we couldn't leverage the PR workflow for this.
> Imagine:
> - You request a new repo to be created
> - The new repo is automatically created from your
On Mon, Oct 07, 2019 at 12:54:56PM +0200, Vít Ondruch wrote:
>
> Dne 07. 10. 19 v 12:00 Pierre-Yves Chibon napsal(a):
> > On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote:
> >> Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a):
> >>> On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon
>
Dne 07. 10. 19 v 12:00 Pierre-Yves Chibon napsal(a):
> On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote:
>> Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a):
>>> On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon
>>> wrote:
On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrot
On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote:
>
> Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a):
> > On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon
> > wrote:
> >> On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
> >>
> >> Thanks for your words, I appreciate the s
* Matthew Miller:
> On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
>> > ○ Every changes to dist-git is done via pull-requests
>> Erm, no thank you. Pull requests are a terrible workflow.
>
> It's definitely the winning workflow in the open source world today,
> particularly f
On 10/4/19 3:17 PM, Björn Persson wrote:
Panu Matilainen wrote:
On 10/2/19 8:33 PM, Matthew Miller wrote:
On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
○ Every changes to dist-git is done via pull-requests
Erm, no thank you. Pull requests are a terrible workflow.
It's
On Sat, Oct 05, 2019 at 02:35:59AM +0200, Kevin Kofler wrote:
> Vít Ondruch wrote:
> > It depends how you maintain your packages. My guess is (and I am sorry
> > if I am mistaken) that you don't follow the
> >
> > https://fedoraproject.org/wiki/Updates_Policy#Philosophy
> >
> > If you followed th
On Wed, Oct 2, 2019 at 1:18 PM Ben Rosser wrote:
>
> 1. Creating new packages has become (more of) a pain since the
> retirement of pkgdb2. I know I keep complaining about needing to
> manually fetch Pagure API keys, but it is actually extremely annoying
> when I go to request a repo and realize
Miro Hrončok wrote:
> Your example is not valid. This is not a mass change, this was an
> individual change presented to the package maintainers via a PR that was
> not merged by me:
>
> https://src.fedoraproject.org/rpms/qt5-qtwebengine/pull-request/3
>
> Had there been a "please, make it build
On 05. 10. 19 2:16, Kevin Kofler wrote:
Miro Hrončok wrote:
It goes like this:
- master and f31 are at the same commit "aa"
- I push a change only possible in rawhide, commit "bb" to master
(it includes release bump and changelog entry)
- a commit relevant for both, "c
Fabio Valentini wrote:
> Additionally, if-guarding every non-backwards compatible change will
> result in unmaintainable, brittle and broken .spec files pretty fast.
> Nobody should be expected to work through if-else-endif spaghetti (and I'm
> not even talking about automated tools here, which alm
On Sat, Oct 5, 2019, 02:17 Kevin Kofler wrote:
> Miro Hrončok wrote:
> > It goes like this:
> >
> > - master and f31 are at the same commit "aa"
> > - I push a change only possible in rawhide, commit "bb" to master
> > (it includes release bump and changelog entry)
> > - a commi
Randy Barlow wrote:
> It's not an either-or. If you resolve the conflict, you can have fast-
> forwarding *and* not pass irrelevant/confusing changelogs on to the end
> user.
>
> I personally avoid if statements in spec files and just resolve
> conflicts.
No. Resolving conflicts implies that you
Vít Ondruch wrote:
> It depends how you maintain your packages. My guess is (and I am sorry
> if I am mistaken) that you don't follow the
>
> https://fedoraproject.org/wiki/Updates_Policy#Philosophy
>
> If you followed this policy, then you would touch the stable branches
> just rarely and theref
Miro Hrončok wrote:
> It goes like this:
>
> - master and f31 are at the same commit "aa"
> - I push a change only possible in rawhide, commit "bb" to master
> (it includes release bump and changelog entry)
> - a commit relevant for both, "cc" is pushed to master
> (it in
On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote:
> >> The package review becomes then a basic PR. We could leverage the tools we
> >> are
> >> working on for regular PRs.
> >> If the PR is approved, you get access granted to it.
> >> If the PR is denied, both repo are deleted.
> > This
Robbie Harwood wrote:
>I have experienced this as a maintainer as well. The issue for drive-by
>contributors is not so much pull requests as the account system itself.
>For example, I had a contributor from OpenSUSE email me patches to my
>pagure-hosted project (gssproxy) rather than opening a pul
Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a):
> On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon wrote:
>> On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
>>
>> Thanks for your words, I appreciate the support on the idea.
>>
>>> 1. Creating new packages has become (more of) a pai
Pierre-Yves Chibon writes:
> On Wed, Oct 02, 2019 at 03:17:33PM -0400, Robbie Harwood wrote:
>
>> With about six more emails about it, sure. And another piece of
>> infrastructure that has to be up and bug-free.
>>
>> Even the gating and bodhi emails today are rather a lot: I don't want to
>> b
On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon wrote:
>
> On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
>
> Thanks for your words, I appreciate the support on the idea.
>
> > 1. Creating new packages has become (more of) a pain since the
> > retirement of pkgdb2. I know I keep com
On Thu, Oct 03, 2019 at 08:07:33AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Yep. Not every package is the same. For stuff like simple
> python/nodejs/rust/ruby/perl/… packages, I know that the only thing
> I do is mechanically bump the version and rebuild. I don't take a careful
> look at the ch
On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
Thanks for your words, I appreciate the support on the idea.
> 1. Creating new packages has become (more of) a pain since the
> retirement of pkgdb2. I know I keep complaining about needing to
> manually fetch Pagure API keys, but it is
On Wed, Oct 02, 2019 at 03:17:33PM -0400, Robbie Harwood wrote:
> With about six more emails about it, sure. And another piece of
> infrastructure that has to be up and bug-free.
>
> Even the gating and bodhi emails today are rather a lot: I don't want to
> be notified if everything worked correc
On Fri, Oct 4, 2019 at 11:03 AM Robbie Harwood wrote:
>
> Björn Persson writes:
>
> > Panu Matilainen wrote:
> >> On 10/2/19 8:33 PM, Matthew Miller wrote:
> >>> On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> >>>
> > ○ Every changes to dist-git is done via pull-requests
Björn Persson writes:
> Panu Matilainen wrote:
>> On 10/2/19 8:33 PM, Matthew Miller wrote:
>>> On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
>>>
> ○ Every changes to dist-git is done via pull-requests
Erm, no thank you. Pull requests are a terrible workflow
Panu Matilainen wrote:
> On 10/2/19 8:33 PM, Matthew Miller wrote:
> > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> >>> ○ Every changes to dist-git is done via pull-requests
> >> Erm, no thank you. Pull requests are a terrible workflow.
> >
> > It's definitely the w
On Thu, Oct 03, 2019 at 08:42:36PM +0200, Clement Verna wrote:
> On Thu, Oct 3, 2019, 17:43 Jeremy Cline wrote:
>
> > On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote:
> > > On Wed, 2 Oct 2019 at 19:34, Matthew Miller
> > > wrote:
> > >
> > > > On Wed, Oct 02, 2019 at 05:31:56PM +01
On Thu, Oct 03, 2019 at 11:42:02AM -0400, Randy Barlow wrote:
> On Thu, 2019-10-03 at 11:58 +0200, Kevin Kofler wrote:
> > I even go as far as reverting branch-only commits and then doing the
> > bidirectional merge trick to restore fast forwardability. That of
> > course
> > clobbers the branch-
On Thu, Oct 3, 2019, 17:43 Jeremy Cline wrote:
> On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote:
> > On Wed, 2 Oct 2019 at 19:34, Matthew Miller
> > wrote:
> >
> > > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> > > > > ○ Every changes to dist-git is done v
On Wed, Oct 2, 2019 at 9:20 PM Neal Gompa wrote:
>
> Unfortunately, it doesn't scale for the large number of packages we
> have. Pull requests would work if we had mergify[1] working on
> Dist-Git, otherwise I can't see how it'd work.
>
> [1]: https://github.com/Mergifyio/mergify-engine
>
>
Sinc
On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote:
> On Wed, 2 Oct 2019 at 19:34, Matthew Miller
> wrote:
>
> > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> > > > ○ Every changes to dist-git is done via pull-requests
> > > Erm, no thank you. Pull requests are
On Thu, 2019-10-03 at 11:58 +0200, Kevin Kofler wrote:
> I even go as far as reverting branch-only commits and then doing the
> bidirectional merge trick to restore fast forwardability. That of
> course
> clobbers the branch-only changelog section and replaces it with the
> one from
> master, bu
On Thu, 3 Oct 2019 at 11:20, Vít Ondruch wrote:
>
>
> Dne 03. 10. 19 v 15:56 Miro Hrončok napsal(a):
> > On 03. 10. 19 15:23, Vít Ondruch wrote:
> >>
> >> Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
> >>> Miro Hrončok wrote:
> On 03. 10. 19 1:32, Kevin Fenzi wrote:
> > I'm not sure how
Dne 03. 10. 19 v 15:56 Miro Hrončok napsal(a):
> On 03. 10. 19 15:23, Vít Ondruch wrote:
>>
>> Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
>>> Miro Hrončok wrote:
On 03. 10. 19 1:32, Kevin Fenzi wrote:
> I'm not sure how to handle the dychomoty between having different
> spec
>
On 03. 10. 19 15:23, Vít Ondruch wrote:
Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
Miro Hrončok wrote:
On 03. 10. 19 1:32, Kevin Fenzi wrote:
I'm not sure how to handle the dychomoty between having different spec
files for each release and wanting to maintain just one spec that has a
bunc
Dne 03. 10. 19 v 14:35 Matthew Miller napsal(a):
> On Wed, Oct 02, 2019 at 04:32:30PM -0700, Kevin Fenzi wrote:
>> I'm not sure how to handle the dychomoty between having different spec
>> files for each release and wanting to maintain just one spec that has a
>> bunch of crazy conditionals in it.
Dne 03. 10. 19 v 12:18 Miro Hrončok napsal(a):
Then obviously, people start inventing %if spaghetti.
Nope,
%if spaghetti
comes from people who are upstream author of some project (usually layered application) and have to support the packages
(usually cli tools for their project) for all Fedo
Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
> Miro Hrončok wrote:
>> On 03. 10. 19 1:32, Kevin Fenzi wrote:
>>> I'm not sure how to handle the dychomoty between having different spec
>>> files for each release and wanting to maintain just one spec that has a
>>> bunch of crazy conditionals in i
On Thu, Oct 03, 2019 at 11:52:32AM +0200, Kevin Kofler wrote:
> Have you seen my reply elsewhere in this thread?
I did, thanks. And I can see that as a fine model too. Looking for more
ideas from Richard as well.
> What is clear is that submitting pull requests to myself does not make any
> sen
On Wed, Oct 02, 2019 at 04:32:30PM -0700, Kevin Fenzi wrote:
> I'm not sure how to handle the dychomoty between having different spec
> files for each release and wanting to maintain just one spec that has a
> bunch of crazy conditionals in it. Even thought I do this too, I think
> we need a workfl
On Wed, 2019-10-02 at 14:44 -0400, Colin Walters wrote:
>
> On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote:
>
> > As others in the thread have pointed out, mandatory pull requests just
> > make no sense for most single-maintainer projects, which most packages
> > probably are.
>
> Well,
On 03. 10. 19 11:58, Kevin Kofler wrote:
I don't understand the people actually maintaining different changelogs for
the releases. I just merge master into the release branches when I push an
update, and if that includes some changelog entries for Rawhide-only mass
rebuilds, so be it. Removing th
Kevin Fenzi wrote:
> I'm not sure how to handle the dychomoty between having different spec
> files for each release and wanting to maintain just one spec that has a
> bunch of crazy conditionals in it. Even thought I do this too, I think
> we need a workflow that discourages this somehow.
I don't
Miro Hrončok wrote:
> On 03. 10. 19 1:32, Kevin Fenzi wrote:
>> I'm not sure how to handle the dychomoty between having different spec
>> files for each release and wanting to maintain just one spec that has a
>> bunch of crazy conditionals in it. Even thought I do this too, I think
>> we need a wo
Matthew Miller wrote:
> Do you have an alternative proposal?
Have you seen my reply elsewhere in this thread?
I wrote there:
> You need a different CI approach. Maybe:
> * a push hook that just locks the repository and does the tests before
> validating the push, though I can see that becomin
On 03. 10. 19 1:32, Kevin Fenzi wrote:
I'm not sure how to handle the dychomoty between having different spec
files for each release and wanting to maintain just one spec that has a
bunch of crazy conditionals in it. Even thought I do this too, I think
we need a workflow that discourages this som
On 10/2/19 8:33 PM, Matthew Miller wrote:
On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
○ Every changes to dist-git is done via pull-requests
Erm, no thank you. Pull requests are a terrible workflow.
It's definitely the winning workflow in the open source world today,
p
On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
> > I'm going to ask again what was in my original email: What is your ideal
> > workflow? How do you think things should work?
> > Is what we have today the ideal state of things?
> > If so, great!
> > If not, what can we improve and are
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
...snip...
So, a few thoughts in general on the thread and ideas...
I think it might be helpfull for us to come up with some personas?
I know that kind of thing seems silly a lot of the time, but I thin
I'm late to the party, but here we go anyway.
Pierre-Yves Chibon writes:
> [snip]
>
> Here is what the vision we came to and that we would like to discuss:
>
> ○ Every changes to dist-git is done via pull-requests
As long as this is not mandatory, sure.
> ○ Pull-requests are automatically test
On Wed, Oct 2, 2019 at 4:06 PM Simo Sorce wrote:
>
> On Wed, 2019-10-02 at 15:57 -0400, Colin Walters wrote:
> >
> > On Wed, Oct 2, 2019, at 3:18 PM, Neal Gompa wrote:
> > > On Wed, Oct 2, 2019 at 2:45 PM Colin Walters wrote:
> > > >
> > > >
> > > >
> > > > On Wed, Oct 2, 2019, at 1:40 PM, Fabio
On Wed, 2019-10-02 at 15:57 -0400, Colin Walters wrote:
>
> On Wed, Oct 2, 2019, at 3:18 PM, Neal Gompa wrote:
> > On Wed, Oct 2, 2019 at 2:45 PM Colin Walters wrote:
> > >
> > >
> > >
> > > On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote:
> > >
> > > > As others in the thread have poi
On Wed, Oct 2, 2019, at 3:18 PM, Neal Gompa wrote:
> On Wed, Oct 2, 2019 at 2:45 PM Colin Walters wrote:
> >
> >
> >
> > On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote:
> >
> > > As others in the thread have pointed out, mandatory pull requests just
> > > make no sense for most single-ma
On Wed, Oct 2, 2019 at 3:18 PM Neal Gompa wrote:
>
> On Wed, Oct 2, 2019 at 2:45 PM Colin Walters wrote:
> >
> >
> >
> > On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote:
> >
> > > As others in the thread have pointed out, mandatory pull requests just
> > > make no sense for most single-mai
On Wed, Oct 2, 2019 at 2:45 PM Colin Walters wrote:
>
>
>
> On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote:
>
> > As others in the thread have pointed out, mandatory pull requests just
> > make no sense for most single-maintainer projects, which most packages
> > probably are.
>
> Well, a
"Colin Walters" writes:
> On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote:
>
>> As others in the thread have pointed out, mandatory pull requests
>> just make no sense for most single-maintainer projects, which most
>> packages probably are.
>
> Well, a lot of this relates to what the *mer
On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote:
> As others in the thread have pointed out, mandatory pull requests just
> make no sense for most single-maintainer projects, which most packages
> probably are.
Well, a lot of this relates to what the *merge policy* is. If a PR submitter
On Wed, Oct 2, 2019 at 8:17 PM Ben Rosser wrote:
>
> On Wed, Oct 2, 2019 at 1:59 PM Pierre-Yves Chibon wrote:
> > There are regularly people complaining on this very list about how hard
> > packaging has become. So here is a thread trying to see if you can come up
> > with
> > a long term, ideal
On Wed, 2 Oct 2019 at 19:34, Matthew Miller
wrote:
> On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> > > ○ Every changes to dist-git is done via pull-requests
> > Erm, no thank you. Pull requests are a terrible workflow.
>
> It's definitely the winning workflow in the open
On Wed, Oct 2, 2019 at 1:59 PM Pierre-Yves Chibon wrote:
> There are regularly people complaining on this very list about how hard
> packaging has become. So here is a thread trying to see if you can come up
> with
> a long term, ideal, vision of what the packager workflow should be so we can
> w
On Wed, Oct 2, 2019 at 7:33 PM Matthew Miller wrote:
>
> On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> > > ○ Every changes to dist-git is done via pull-requests
> > Erm, no thank you. Pull requests are a terrible workflow.
>
> It's definitely the winning workflow in the op
* Matthew Miller [02/10/2019 13:33] :
>
>And there _are_ real tracking and review benefits to
> having everything go through that workflow.
>
> Do you have an alternative proposal?
I'm fine with the workflow we have now. Small and drive-by contributions
can by contributed via
On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> > ○ Every changes to dist-git is done via pull-requests
> Erm, no thank you. Pull requests are a terrible workflow.
It's definitely the winning workflow in the open source world today,
particularly for smaller and drive-by cont
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> ○ Every changes to dist-git is done via pull-requests
Erm, no thank you. Pull requests are a terrible workflow.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and v
On Wed, Oct 2, 2019 at 8:42 AM Stephen John Smoogen wrote:
>
> On Wed, 2 Oct 2019 at 03:39, Felix Schwarz wrote:
> >
> >
> > Am 01.10.19 um 16:55 schrieb Stephen John Smoogen:
> > > Then there are problems with budgets and figuring out what exactly it
> > > would cost. We fall outside of many of
On Wed, 2 Oct 2019 at 03:39, Felix Schwarz wrote:
>
>
> Am 01.10.19 um 16:55 schrieb Stephen John Smoogen:
> > Then there are problems with budgets and figuring out what exactly it
> > would cost. We fall outside of many of the 'caveats' that would allow
> > us to get free.
>
> IIRC at the time wh
On Wed, Oct 02, 2019 at 03:29:23AM +0200, Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 11:30:28AM -0700, Troy Dawson wrote:
> > On Thu, Sep 26, 2019 at 10:48 AM Robbie Harwood wrote:
> > >
> > > Pierre-Yves Chibon writes:
> > >
> > > > Here is what the vision we came to and that we would l
On Thu, Sep 26, 2019 at 03:33:11PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 26, 2019 at 04:24:29PM +0200, Pierre-Yves Chibon wrote:
> > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> > > > Good Mo
On Thu, Sep 26, 2019 at 11:23:21AM -0500, Michael Cronenworth wrote:
> On 9/26/19 10:28 AM, Pierre-Yves Chibon wrote:
> > Would this change if the PR was automatically tested for you without you
> > having
> > to do anything?
>
> I always run local mock builds prior to commits. Maybe not everyone
On Thu, Sep 26, 2019 at 11:24:28AM -0500, Michael Cronenworth wrote:
> On 9/26/19 9:07 AM, Pierre-Yves Chibon wrote:
> > What is so different in Fedora that we cannot move to this model?
> > Is it a tooling issue?
> > Is it something else?
>
> As others have already stated that may work in project
On Thu, Sep 26, 2019 at 11:30:28AM -0700, Troy Dawson wrote:
> On Thu, Sep 26, 2019 at 10:48 AM Robbie Harwood wrote:
> >
> > Pierre-Yves Chibon writes:
> >
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git is done via pull-request
On Wed, 2019-10-02 at 09:39 +0200, Felix Schwarz wrote:
> Am 01.10.19 um 16:55 schrieb Stephen John Smoogen:
> > Then there are problems with budgets and figuring out what exactly it
> > would cost. We fall outside of many of the 'caveats' that would allow
> > us to get free.
>
> IIRC at the time
Am 01.10.19 um 16:55 schrieb Stephen John Smoogen:
Then there are problems with budgets and figuring out what exactly it
would cost. We fall outside of many of the 'caveats' that would allow
us to get free.
IIRC at the time when Fedora evaluated its options the open source version of
Gitlab w
On Tuesday, October 1, 2019 7:55:10 AM MST Stephen John Smoogen wrote:
> Then when GitHub started to take over, it is closed source and that
> was a big nono for services from Fedora developers. [AKA we move to
> Github various package owners were going to drop their packages and
> leave.]
This i
On Tue, 1 Oct 2019 at 10:18, Joe Doss wrote:
>
> On 9/26/19 11:57 AM, Ken Dreyer wrote:
> > I would like to hear if you see Pagure as still strategic, and if so,
> > how we can make these common user operations faster.
>
> I always wondered why Fedora home rolled their own Github/Gitlab clone.
Be
On 9/26/19 11:57 AM, Ken Dreyer wrote:
I would like to hear if you see Pagure as still strategic, and if so,
how we can make these common user operations faster.
I always wondered why Fedora home rolled their own Github/Gitlab clone.
Using either Github or Gitlab would be better for new users
Il giorno ven, 27/09/2019 alle 08.31 +, Petr Pisar ha scritto:
> On 2019-09-26, Pierre-Yves Chibon wrote:
> > ○ Every changes to dist-git is done via pull-requests
>
> Pull requests are great for proposing your changes to foreign
> packages.
> It does not make sense when maintaining the code.
"Michael J Gruber" writes:
> There is the current worklflow and the current mindset. One influences
> the other.
>
> For a long-time gitter, the prevailing Fedora packager mindset is
> still very much "dist-cvs". dist-git is often used as merely a tool to
> drive "dist-something", not so much as
On 27/09/2019 00:04, Miro Hrončok wrote:
On 26. 09. 19 22:06, Jason L Tibbitts III wrote:
"C" == Christopher writes:
C> With version-controlled package sources, changelogs in SPEC seem so
C> obsolete to me. They are already problematic today when they conflict
C> due to changes in multiple b
There is the current worklflow and the current mindset. One influences the
other.
For a long-time gitter, the prevailing Fedora packager mindset is still very
much "dist-cvs". dist-git is often used as merely a tool to drive
"dist-something", not so much as a vcs, and really rarely as a tool fo
On 9/27/19 5:57 PM, Neal Gompa wrote:
On Fri, Sep 27, 2019 at 9:54 AM Panu Matilainen wrote:
On 9/26/19 10:05 PM, Jeremy Cline wrote:
On Thu, Sep 26, 2019 at 02:57:56PM -0400, Randy Barlow wrote:
On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
The combination of these two makes no se
On 2019-09-27 17:46, Randy Barlow wrote:
On Fri, 2019-09-27 at 10:26 +0200, Michal Konecny wrote:
There is still possibility to use libraries.io
instead of Anitya, but there are some issues:
- lack of downstream mapping (this could be easily solved by some
database with only downstream mapping
1 - 100 of 181 matches
Mail list logo
