On Fri, Sep 27, 2019 at 10:57:21AM -0400, 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:
>
On Thu, Sep 26, 2019, at 10:24 AM, Pierre-Yves Chibon wrote:
> I like this.
> It means that the build-system would have to generate the tarball of the
> source
> and put it into dist-git at srpm-build time (I believe we still want to store
> a
> copy of the sources used for a build).
https://gi
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)
> - lack of custom project additio
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 sense to me. I do plenty of
On Fri, 2019-09-27 at 00:20 +0200, Dan Čermák wrote:
> Randy Barlow writes:
>
> > This suggestion gives a nice clean place to write the bodhi update
> > description, right in git. The commit messages can remain the way they
> > are today: authored for the audience of spec file contributors.
> >
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 sense to me. I do plenty of
work
where I don't want to build it (specfile cleanup, patches,
configu
On Fri, Sep 27, 2019 at 12:40:42PM +0200, Martin Kolman wrote:
> On Thu, 2019-09-26 at 16:24 +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 Morning Everyo
On Thu, 2019-09-26 at 16:24 +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 Morning Everyone,
> > >
> > > At Flock, a few of us met to discuss a future vision o
On Thu, 2019-09-26 at 18:26 +0200, Ben Rosser wrote:
> On Thu, Sep 26, 2019 at 5:29 PM Pierre-Yves Chibon
> wrote:
> > On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote:
> > > On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon
> > > wrote:
> > > > There is a clear initial rejection of
On Fri, Sep 27, 2019 at 11:56 AM Miro Hrončok wrote:
> Yes. I've em-mailed you about the problem when it was happening, asking
> you to
> disable it, there was no reply and I managed to build it at the end.
>
>
So, I apologize. I missed your email.
___
On 27. 09. 19 11:50, Fabien Boucher wrote:
I remember that during the Python 3.8 rebuilds in the side tag, one package
had
this automated somehow already. I was bumping the release/changelog and
trying
to build it in the side tag at least 5 times, but I was building with
--backg
On Fri, Sep 27, 2019 at 12:03 AM Miro Hrončok wrote:
> I remember that during the Python 3.8 rebuilds in the side tag, one
> package had
> this automated somehow already. I was bumping the release/changelog and
> trying
> to build it in the side tag at least 5 times, but I was building with
> --b
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. Either when doing
a mass changes like rebuilding all Perl packages against a n
On 2019-09-26 20:35, Jeremy Cline wrote:
On Thu, Sep 26, 2019 at 09:08:16AM -0700, Adam Williamson wrote:
On Thu, 2019-09-26 at 15:46 +, Jeremy Cline wrote:
Ah right, that makes a lot of sense.
I can imagine automatically detecting the new upstream release, building
that, and presenting
Christopher writes:
> I just don't see this proposed workflow as solving the biggest
> problems that packagers face. For me, I think the biggest problem that
> packagers (particularly newer packagers) face is discovery of all the
> services involved in the packaging workflow, and the need to visi
* Pierre-Yves Chibon [26/09/2019 16:07] :
>
> When we work on upstream projects, I think it's pretty standard now to always
> go
> via PRs, even for your own branch.
FWIW, this workflow makes sense for one that has a community but it sounds very
strange to do this on a project on which you are th
Randy Barlow writes:
> This suggestion gives a nice clean place to write the bodhi update
> description, right in git. The commit messages can remain the way they
> are today: authored for the audience of spec file contributors.
>
> We could also support special syntax in the tag message to allow
On Thu, 26 Sep 2019 at 16:46, Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > Allow packagers to have a clone of the upstraem git repo
>
> - What about the upstream projects that still only publish a tarball at
> release?
What about upstream
Daniel P. Berrangé writes:
> On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
>
> For packages I maintain, my preference is to touch dist-git as little
> as possible. Ideally I would never touch dist-git at all & rather wish
> it didn't exist at all in its current form of spec+
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 branches.
It's important to note that the
On 26. 09. 19 11:36, Pierre-Yves Chibon wrote:
○ Every commit to dist-git (ie: PR merged) is automatically built in koji
If we go this way, there must be a way to disable this or to dictate what side
tag this needs to be built in.
I remember that during the Python 3.8 rebuilds in the side ta
On 26. 09. 19 21:47, Randy Barlow wrote:
On Thu, 2019-09-26 at 19:05 +, Jeremy Cline wrote:
The tag also provides a nice place to write release notes for the
update. I suppose you could also add support for some sort of text
tag
inside commits (like when you mark a commit as fixing an issue
On 26. 09. 19 22:37, Tristan Cacqueray wrote:
Note that git-pull-requests now support pagure. The tool takes care of
creating the fork, pushing the local changes and opening the PR:
https://github.com/Mergifyio/git-pull-request
Will definitively test this soon, thanks!
If it works, we shoul
On Thu, Sep 26, 2019 at 15:49 Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 03:40:49PM +0200, Miroslav Suchý wrote:
>> Dne 26. 09. 19 v 15:10 Pierre-Yves Chibon napsal(a):
>> > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
>> > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écr
> "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 branches.
It's important to note that the RPM changelog is rather a different
thing from
On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> > ○ Every commit to dist-git (ie: PR merged) is automatically built
> > in koji
> > ○ Every build in koji results automatically in an update in bodhi
>
> The combination of these two makes no sense to me. I do plenty of
> work
> where I don'
On Thu, 2019-09-26 at 19:05 +, Jeremy Cline wrote:
> The tag also provides a nice place to write release notes for the
> update. I suppose you could also add support for some sort of text
> tag
> inside commits (like when you mark a commit as fixing an issue in
> Git{Lab,Hub} and look at the co
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 sense to me. I do plenty of
> > work
> > where I don't want to build it (specfile cleanup, patches,
> > configuration
> > changes, etc.).
On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> The combination of these two makes no sense to me. I do plenty of
> work
> where I don't want to build it (specfile cleanup, patches,
> configuration
> changes, etc.). I want a build that goes to users be explicit.
>
> A better model, in my
On Thu, 2019-09-26 at 08:58 -0700, Brian C. Lane wrote:
> I'm also not clear on where the .spec files and tests would live if
> you
> are using a fork of the upstream. We still need dist-git to store
> those,
> even if everything that touches them is a tool other than vim. Or
> maybe
> I missed som
On Thu, Sep 26, 2019 at 09:08:16AM -0700, Adam Williamson wrote:
> On Thu, 2019-09-26 at 15:46 +, Jeremy Cline wrote:
> >
> > Ah right, that makes a lot of sense.
> >
> > I can imagine automatically detecting the new upstream release, building
> > that, and presenting the packager with a easy
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-requests
> > ○ Pull-requests are automatically tested
> > ○ Every commit to dist-g
On Thu, Sep 26, 2019 at 01:22:03PM -0400, Robert Marcano via devel wrote:
> On 9/26/19 12:57 PM, Ken Dreyer wrote:
> > On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon
> > wrote:
> > >
> > > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > > > Le 26/09/2019 à 11:36, Pierre-Yves
Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
>> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
>> > 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
>>
>> IMHO Hav
On Thu, Sep 26, 2019 at 8:33 AM Pierre-Yves Chibon wrote:
>
> Good Morning Everyone,
>
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization that a number of initiatives
> are happening around packaging in Fedora but the
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-requests
> ○ Pull-requests are automatically tested
> ○ Every commit to dist-git (ie: PR merged) is automatically built in koji
> ○ Every build in ko
On 9/26/19 12:57 PM, Ken Dreyer wrote:
On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon wrote:
On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
Here is what the vision we came to and that we would like to discuss:
○ Every cha
On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git is
* Unclear work-
On 9/26/19 7:07 AM, Pierre-Yves Chibon wrote:
When we work on upstream projects, I think it's pretty standard now to always go
via PRs, even for your own branch.
So that tests are run, so that other member of the community can see, comment,
review the change.
What is so differen
On Thu, Sep 26, 2019 at 5:29 PM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote:
> > On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon
> > wrote:
> > > There is a clear initial rejection of a PR-only contribution model. I
> > > hear that
> > > and that
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 projects with tens, hundreds, or
thousands of contributors, but most of Fedora packages ar
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 likes to do this
and wants Koji to do it for them, but I prefer local mock builds.
On Thu, 2019-09-26 at 15:46 +, Jeremy Cline wrote:
>
> Ah right, that makes a lot of sense.
>
> I can imagine automatically detecting the new upstream release, building
> that, and presenting the packager with a easy-to-review PR that you just
> click "merge" on instead of pointing the specfi
On 9/26/19 11:14 AM, Fabio Valentini wrote:
> On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline wrote:
>>
>> On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
>>> On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
>>> wrote:
On Thu, Sep 26, 2019 at 02:57:45PM +0100, D
On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
[snip]
> Allow packagers to have a clone of the upstraem git repo, and use the
> pull-requests and run Fedora CI testing against the Fedora branch of
> the upstream repo instead of against dist-git.
>
> In this way, maintaining
On Thu, Sep 26, 2019 at 05:14:59PM +0200, Fabio Valentini wrote:
> On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline wrote:
> >
> > On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
> > > On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > > >
> > > > On Thu, Se
On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote:
> On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon
> wrote:
> > There is a clear initial rejection of a PR-only contribution model. I hear
> > that
> > and that may mean that we never go this way. I'm honestly fine with that :)
> > I
On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline wrote:
>
> On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
> > On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > > Instead I pre
On 26.09.2019 15:10, Pierre-Yves Chibon wrote:
> What makes it a headache? What can we do to not have this be a terrible
> headache? Can we fix/improve the tooling?
I'm not going to log in into web, create a new pr, then merge it. This
is a terrible idea. Do not change current workflow.
--
Since
On 26.09.2019 11:36, Pierre-Yves Chibon wrote:
> ○ Every changes to dist-git is done via pull-requests
No way! This is a terrible idea.
> ○ Every build in koji results automatically in an update in bodhi
Not good too.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
_
On Thu, Sep 26, 2019 at 4:50 PM Fabio Valentini wrote:
>
> On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > Instead I prefer a clone of the master upstream git repo and maintain a
> > > branch wi
On Thu, Sep 26, 2019 at 04:16:46PM +0200, Fabio Valentini wrote:
> > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji
>
> I don't think this is wise. On the one hand, it will create even more
> workload in koji, and on the other hand, running "fedpkg build" for
> things I
On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
> On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > Instead I prefer a clone of the master upstream git repo and maintain a
> > > br
On 26. 09. 19 11:36, Pierre-Yves Chibon wrote:
○ Every changes to dist-git is done via pull-requests
I like this idea, however as other has pointed out, it needs to be much smoother
experience than now.
See for example this RFE:
number 3)
https://lists.fedoraproject.org/archives/list/devel
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
>
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization that a number of initiatives
> are happening around packaging in Fedora
On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > Instead I prefer a clone of the master upstream git repo and maintain a
> > branch with patches cherry-picked into it. This is used to auto-generate
> > pa
On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon wrote:
> There is a clear initial rejection of a PR-only contribution model. I hear
> that
> and that may mean that we never go this way. I'm honestly fine with that :)
> I do want to see why that is a show-stopper and if we can find ways to not
On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> Instead I prefer a clone of the master upstream git repo and maintain a
> branch with patches cherry-picked into it. This is used to auto-generate
> patches for the Fedora RPM, at the same time updating the patch file list
> in t
On Thu, Sep 26, 2019 at 04:07:59PM +0200, Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 08:47:24AM -0500, Michael Cronenworth wrote:
> > On 9/26/19 8:42 AM, Pierre-Yves Chibon wrote:
> > > Again, I'd like to reinforce that the idea is not to enforce any part of
> > > this
> > > workflow tomo
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 Morning Everyone,
> > >
> > > At Flock, a few of us met to discuss a future v
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 Morning Everyone,
> >
> > At Flock, a few of us met to discuss a future vision of the packager
> > workflow.
> > This discussion was triggered by the
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
>
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization that a number of initiatives
> are happening around packaging in Fedora
On Thu, Sep 26, 2019 at 2:32 PM Pierre-Yves Chibon wrote:
>
> Good Morning Everyone,
Alright. I don't often reply to discussion threads like this, but here we go.
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization t
On Thu, Sep 26, 2019 at 6:56 AM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 06:38:45AM -0700, Troy Dawson wrote:
> > On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon
> > wrote:
> > >
> > > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > > > Le 26/09/2019 à 11:36, Pie
On Thu, Sep 26, 2019 at 08:47:24AM -0500, Michael Cronenworth wrote:
> On 9/26/19 8:42 AM, Pierre-Yves Chibon wrote:
> > Again, I'd like to reinforce that the idea is not to enforce any part of
> > this
> > workflow tomorrow, it'll be a smooth, slow and long transition. My question
> > is
> > whe
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
>
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization that a number of initiatives
> are happening around packaging in Fedora
Le 26/09/2019 à 15:10, Pierre-Yves Chibon a écrit :
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
>> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
>>> Here is what the vision we came to and that we would like to discuss:
>>>
>>> ○ Every changes to dist-git is done via pull-re
On Thu, Sep 26, 2019 at 06:38:45AM -0700, Troy Dawson wrote:
> On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon
> wrote:
> >
> > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > > Here is what the vision we came to and
Dne 26. 09. 19 v 11:36 Pierre-Yves Chibon napsal(a):
- We need to work on the change logs in the spec files, as otherwise
pull-requests are going to conflict more often than not
+1
Thou, I would love to have general solution. Not just Fedora-centric. Something which will respect use-case of
On Thu, Sep 26, 2019 at 03:40:49PM +0200, Miroslav Suchý wrote:
> Dne 26. 09. 19 v 15:10 Pierre-Yves Chibon napsal(a):
> > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > > Here is what the vision we came to and that we wo
On 9/26/19 8:42 AM, Pierre-Yves Chibon wrote:
Again, I'd like to reinforce that the idea is not to enforce any part of this
workflow tomorrow, it'll be a smooth, slow and long transition. My question is
whether this is a place where we want to go or can we come up with a
different/better one?:)
On Thu, Sep 26, 2019 at 09:14:38AM -0400, Stephen John Smoogen wrote:
> On Thu, 26 Sep 2019 at 09:02, Remi Collet wrote:
> >
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git i
On Thu, Sep 26, 2019 at 01:15:03PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every change
Dne 26. 09. 19 v 15:10 Pierre-Yves Chibon napsal(a):
On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
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
IMH
On Thursday, 26 September 2019 15:01:25 CEST Remi Collet wrote:
> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
>
> > 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
>
>
> IMHO Have to stay optional, makin
On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git is
On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > 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
>
> IMHO Have to stay optional, making this ma
On Thu, 26 Sep 2019 at 09:02, Remi Collet wrote:
>
> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > 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
>
> IMHO Have to stay optional, making this mandatory bei
On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > 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
>
> IMHO Have to stay optional, making this ma
Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> 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
IMHO Have to stay optional, making this mandatory being a terrible headache.
RFemi
___
101 - 180 of 180 matches
Mail list logo
