6:03 a.m.
Hi all.
I have created a fork on https://src.fedoraproject.org/ but i don't know
how to manage it.
Can i use 'fedpkg'?
Documentation?
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/
11:52 a.m.
On Wed, Nov 29, 2017, at 01:03 PM, Antonio Trande wrote:
Hi all.
I have created a fork on https://src.fedoraproject.org/ but i
don't know> how to manage it.
Can i use 'fedpkg'?
Documentation?
As as you have a fork, my understanding is that you should just use
traditional gut commands. I’m not aware of a fork being used for much
more than spec PRs.
Regards,
bex
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Email had 1 attachment:
+ signature.asc
1k (application/pgp-signature)
12:53 p.m.
On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
As as you have a fork, my understanding is that you should just use
traditional gut commands. I’m not aware of a fork being used for much
more than spec PRs.
Or traditional _git_ commands -- whatever. :)
Personally, I find that when working with forks of something where I'm
a casual contributor, I end up doing this a lot:
git remote add upstream https://pagure.io/fedora-docs/quick-docs
git fetch upstream
git reset --hard upstream/master
(repeat last two steps)
Because I don't really want to keep a long-lived fork with local
changes and differences and merge. Possibly fedpkg could grow something
smart around this?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:06 p.m.
On 11/29/2017 10:53 AM, Matthew Miller wrote:
On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
> As as you have a fork, my understanding is that you should just use
> traditional gut commands. I’m not aware of a fork being used for much
> more than spec PRs.
Or traditional _git_ commands -- whatever. :)
Personally, I find that when working with forks of something where I'm
a casual contributor, I end up doing this a lot:
git remote add upstream https://pagure.io/fedora-docs/quick-docs
git fetch upstream
git reset --hard upstream/master
(repeat last two steps)
I'm sure places like github have docs on this too, but pagure also does:
https://docs.pagure.org/pagure/usage/forks.html
There's one big gotcha to note with forks on src.fedoraproject.org:
You have to be in the packager group to push changes to anything there
(including forks) at least for now. We want to change this, but it will
require a fair bit of shifting things around.
You can still of course make a copy of the repo on any other public
place (pagure.io, github, gitlab, etc) and file "remote pull requests"
in the mean time.
Because I don't really want to keep a long-lived fork with local
changes and differences and merge. Possibly fedpkg could grow something
smart around this?
Possibly. It's also worth noting that some people use a workflow like:
* fork project
* make changes, submit PR
* delete fork
that way the next time you can just refork it and be set.
kevin
1:39 p.m.
On Wed, Nov 29, 2017 at 11:06:30AM -0800, Kevin Fenzi wrote:
Possibly. It's also worth noting that some people use a workflow
like:
* fork project
* make changes, submit PR
* delete fork
that way the next time you can just refork it and be set.
Yeah, that's fine too. Especially if you're just making one change.
It's kind of a pain to clean up, though. Oooh:
https://pagure.io/pagure/issue/2808
(Also I found https://pagure.io/pagure/issue/836)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:15 a.m.
Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
On 11/29/2017 10:53 AM, Matthew Miller wrote:
> On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>> As as you have a fork, my understanding is that you should just use
>> traditional gut commands. I’m not aware of a fork being used for much
>> more than spec PRs.
> Or traditional _git_ commands -- whatever. :)
>
> Personally, I find that when working with forks of something where I'm
> a casual contributor, I end up doing this a lot:
>
> git remote add upstream https://pagure.io/fedora-docs/quick-docs
>
> git fetch upstream
> git reset --hard upstream/master
>
>
> (repeat last two steps)
I'm sure places like github have docs on this too, but pagure also does:
https://docs.pagure.org/pagure/usage/forks.html
Sorry to say that, but I consider this page ill advised. E.g. suggesting
to do:
~~~
$ git clone ssh://git@pagure.io/forks/jcline/pagure.git
~~~
is totally wrong IMO. I would go as far as saying you should never "git
clone" forked repository. You should always "git clone" the upstream and
then add the remote for your fork if you need.
The main reason is because you want to follow your upstream. You want to
be able to "git pull" from the master branch and get the latest and
greatest. That is where the development happens. Your fork is mostly
just tool enabling you to send PR and that happens typically just once
in a while if ever.
Vít
There's one big gotcha to note with forks on src.fedoraproject.org:
You have to be in the packager group to push changes to anything there
(including forks) at least for now. We want to change this, but it will
require a fair bit of shifting things around.
You can still of course make a copy of the repo on any other public
place (pagure.io, github, gitlab, etc) and file "remote pull requests"
in the mean time.
> Because I don't really want to keep a long-lived fork with local
> changes and differences and merge. Possibly fedpkg could grow something
> smart around this?
Possibly. It's also worth noting that some people use a workflow like:
* fork project
* make changes, submit PR
* delete fork
that way the next time you can just refork it and be set.
kevin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
6:48 a.m.
On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
On 11/29/2017 10:53 AM, Matthew Miller wrote:
On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
As as you have a fork, my understanding is that you should just use
traditional gut commands. I’m not aware of a fork being used for much
more than spec PRs.
Or traditional _git_ commands -- whatever. :)
Personally, I find that when working with forks of something where I'm
a casual contributor, I end up doing this a lot:
git remote add upstream https://pagure.io/fedora-docs/quick-docs
git fetch upstream
git reset --hard upstream/master
(repeat last two steps)
I'm sure places like github have docs on this too, but pagure also does:
https://docs.pagure.org/pagure/usage/forks.html
Sorry to say that, but I consider this page ill advised. E.g. suggesting
to do:
~~~
$ git clone ssh://git@pagure.io/forks/jcline/pagure.git
~~~
is totally wrong IMO.
That is most definitively just your opinion :)
I know many people seeing it the other way around. They fork their repo,
potentially add upstream as another remote, push to their fork, open their PR
and practically will only pull from upstream if upstream asks them to rebase or
if they need to do another change.
I would go as far as saying you should never "git
clone" forked repository. You should always "git clone" the upstream
and
then add the remote for your fork if you need.
It's really potato vs potato, clone your fork and add upstream as a remote or
clone upstream and add your fork as a remote, at the end what matters is that
you know which approach you used (and if you don't git remote -v will tell you)
and know how to work with it.
Pierre
7:55 a.m.
Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
> Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
>
> On 11/29/2017 10:53 AM, Matthew Miller wrote:
>
> On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>
> As as you have a fork, my understanding is that you should just use
> traditional gut commands. I’m not aware of a fork being used for much
> more than spec PRs.
>
> Or traditional _git_ commands -- whatever. :)
>
> Personally, I find that when working with forks of something where I'm
> a casual contributor, I end up doing this a lot:
>
> git remote add upstream https://pagure.io/fedora-docs/quick-docs
>
> git fetch upstream
> git reset --hard upstream/master
>
>
> (repeat last two steps)
>
> I'm sure places like github have docs on this too, but pagure also does:
>
> https://docs.pagure.org/pagure/usage/forks.html
>
> Sorry to say that, but I consider this page ill advised. E.g. suggesting
> to do:
>
> ~~~
>
> $ git clone ssh://git@pagure.io/forks/jcline/pagure.git
>
> ~~~
>
> is totally wrong IMO.
That is most definitively just your opinion :)
I know many people seeing it the other way around. They fork their repo,
potentially add upstream as another remote, push to their fork, open their PR
and practically will only pull from upstream if upstream asks them to rebase or
And that is the major problem with that approach. In this case upstream
has often to tell something to people submitting their PR and just
because the plain "git pull" can't do the right and natural thing.
People then start their branches from obsolete master etc.
If you clone the upstream repository, then you never have to pull
anything from your fork. You are using the fork in "push only" mode.
if they need to do another change.
> I would go as far as saying you should never "git
> clone" forked repository. You should always "git clone" the
upstream and
> then add the remote for your fork if you need.
It's really potato vs potato, clone your fork and add upstream as a remote or
clone upstream and add your fork as a remote, at the end what matters is that
you know which approach you used (and if you don't git remote -v will tell you)
and know how to work with it.
Not really, it is matter of attitude. Clone of upstream is always good
to have. Just for observing the project or to prepare source tarball or
whatever else. Fork itself is useless unless you want to contribute.
Vít
8:03 a.m.
On Thu, Nov 30, 2017 at 02:55:50PM +0100, Vít Ondruch wrote:
Not really, it is matter of attitude. Clone of upstream is always
good
to have. Just for observing the project or to prepare source tarball or
whatever else. Fork itself is useless unless you want to contribute.
I can see the sense in this workflow -- it might be nice to have
documentation for both, and perhaps even showing instructions for
cloning the original and setting the remote for the fork when viewing a
fork.
I bet Pierre would accept patches.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:04 a.m.
On Thu, Nov 30, 2017 at 8:55 AM, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
>> Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
>>
>> On 11/29/2017 10:53 AM, Matthew Miller wrote:
>>
>> On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>>
>> As as you have a fork, my understanding is that you should just use
>> traditional gut commands. I’m not aware of a fork being used for much
>> more than spec PRs.
>>
>> Or traditional _git_ commands -- whatever. :)
>>
>> Personally, I find that when working with forks of something where I'm
>> a casual contributor, I end up doing this a lot:
>>
>> git remote add upstream https://pagure.io/fedora-docs/quick-docs
>>
>> git fetch upstream
>> git reset --hard upstream/master
>>
>>
>> (repeat last two steps)
>>
>> I'm sure places like github have docs on this too, but pagure also does:
>>
>> https://docs.pagure.org/pagure/usage/forks.html
>>
>> Sorry to say that, but I consider this page ill advised. E.g. suggesting
>> to do:
>>
>> ~~~
>>
>> $ git clone ssh://git@pagure.io/forks/jcline/pagure.git
>>
>> ~~~
>>
>> is totally wrong IMO.
> That is most definitively just your opinion :)
>
> I know many people seeing it the other way around. They fork their repo,
> potentially add upstream as another remote, push to their fork, open their PR
> and practically will only pull from upstream if upstream asks them to rebase or
And that is the major problem with that approach. In this case upstream
has often to tell something to people submitting their PR and just
because the plain "git pull" can't do the right and natural thing.
People then start their branches from obsolete master etc.
If you clone the upstream repository, then you never have to pull
anything from your fork. You are using the fork in "push only" mode.
> if they need to do another change.
>
>> I would go as far as saying you should never "git
>> clone" forked repository. You should always "git clone" the
upstream and
>> then add the remote for your fork if you need.
> It's really potato vs potato, clone your fork and add upstream as a remote or
> clone upstream and add your fork as a remote, at the end what matters is that
> you know which approach you used (and if you don't git remote -v will tell you)
> and know how to work with it.
Not really, it is matter of attitude. Clone of upstream is always good
to have. Just for observing the project or to prepare source tarball or
whatever else. Fork itself is useless unless you want to contribute.
This is going to be a pointless never ending debate. Git is flexible
enough to let you do this in multiple ways, people are going to have
their preferences. Just agree to disagree and move on.
I mean, come on. It took years for vim to win the editor wars. We
don't have time to waste on another debate like that ;)
josh
8:06 a.m.
On Thu, Nov 30, 2017 at 02:55:50PM +0100, Vít Ondruch wrote:
Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
>> Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
>>
>> On 11/29/2017 10:53 AM, Matthew Miller wrote:
>>
>> On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>>
>> As as you have a fork, my understanding is that you should just use
>> traditional gut commands. I’m not aware of a fork being used for much
>> more than spec PRs.
>>
>> Or traditional _git_ commands -- whatever. :)
>>
>> Personally, I find that when working with forks of something where I'm
>> a casual contributor, I end up doing this a lot:
>>
>> git remote add upstream https://pagure.io/fedora-docs/quick-docs
>>
>> git fetch upstream
>> git reset --hard upstream/master
>>
>>
>> (repeat last two steps)
>>
>> I'm sure places like github have docs on this too, but pagure also does:
>>
>> https://docs.pagure.org/pagure/usage/forks.html
>>
>> Sorry to say that, but I consider this page ill advised. E.g. suggesting
>> to do:
>>
>> ~~~
>>
>> $ git clone ssh://git@pagure.io/forks/jcline/pagure.git
>>
>> ~~~
>>
>> is totally wrong IMO.
> That is most definitively just your opinion :)
>
> I know many people seeing it the other way around. They fork their repo,
> potentially add upstream as another remote, push to their fork, open their PR
> and practically will only pull from upstream if upstream asks them to rebase or
And that is the major problem with that approach. In this case upstream
has often to tell something to people submitting their PR and just
because the plain "git pull" can't do the right and natural thing.
People then start their branches from obsolete master etc.
If you clone the upstream repository, then you never have to pull
anything from your fork. You are using the fork in "push only" mode.
> if they need to do another change.
>
>> I would go as far as saying you should never "git
>> clone" forked repository. You should always "git clone" the
upstream and
>> then add the remote for your fork if you need.
> It's really potato vs potato, clone your fork and add upstream as a remote or
> clone upstream and add your fork as a remote, at the end what matters is that
> you know which approach you used (and if you don't git remote -v will tell you)
> and know how to work with it.
Not really, it is matter of attitude. Clone of upstream is always good
to have. Just for observing the project or to prepare source tarball or
whatever else. Fork itself is useless
unless you want to contribute.
Which is exactly what this documentation is about :)
Anyway, no point in arguing further I believe. If you think the documentation
can be improved the sources are in the ``doc`` folder in pagure's sources and
suggestions are welcome :)
Pierre
8:51 a.m.
Vít Ondruch wrote:
Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> It's really potato vs potato, clone your fork and add upstream as a
> remote or clone upstream and add your fork as a remote, at the end
> what matters is that you know which approach you used (and if you
> don't git remote -v will tell you) and know how to work with it.
Not really, it is matter of attitude. Clone of upstream is always
good to have. Just for observing the project or to prepare source
tarball or whatever else.
If you clone from the fork and add the upstream as a remote, you have
a clone of the upstream. All that really differs is which one is named
origin. And that's only the default remote name. It's easy to change
that during clone with the --origin option or later with git remote
rename.
Depending on the audience and their familiarity with git, it may be
easier to explain one method or the other. But in terms of what data
the git repository contains, they're essentially identical.
Fork itself is useless unless you want to contribute.
That's precisely the audience for the forks documentation, as far as I
can see. The documentation states that in the second sentence. :)
I don't particularly think it's needed, but perhaps someone who does
would want to submit something like this to the documentation:
---- 8< ----
diff --git i/doc/usage/forks.rst w/doc/usage/forks.rst
index 362280d4..dfc46412 100644
--- i/doc/usage/forks.rst
+++ w/doc/usage/forks.rst
@@ -42,6 +42,12 @@ example::
This lets you pull in changes that the upstream repository makes after you
forked. Consult Git's documentation for more details.
+Alternatively, if you already have a clone of the upstream, you can add your
+fork as a remote. For example::
+
+ $ cd pagure
+ $ git remote add -f my-fork ssh://git@pagure.io/forks/jcline/pagure.git
+
Pushing Changes
---------------
---- 8< ----
And if there is some reasonable documentation online which further
explains the benefits of each approach it might be worth adding as a
link below. For all I know, the ProGit "Distributed Workflows" page
which is referenced at the beginning of the Pagure forks documentation
covers this.
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stress is when you wake up screaming and you realize you weren't
sleeping.
10:02 a.m.
----- Original Message -----
From: "Vít Ondruch" <vondruch(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Sent: Thursday, November 30, 2017 2:55:50 PM
Subject: Re: How to manage a fork
Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
>> Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
>>
>> On 11/29/2017 10:53 AM, Matthew Miller wrote:
>>
>> On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>>
>> As as you have a fork, my understanding is that you should just use
>> traditional gut commands. I’m not aware of a fork being used for much
>> more than spec PRs.
>>
>> Or traditional _git_ commands -- whatever. :)
>>
>> Personally, I find that when working with forks of something where I'm
>> a casual contributor, I end up doing this a lot:
>>
>> git remote add upstream https://pagure.io/fedora-docs/quick-docs
>>
>> git fetch upstream
>> git reset --hard upstream/master
>>
>>
>> (repeat last two steps)
>>
>> I'm sure places like github have docs on this too, but pagure also does:
>>
>> https://docs.pagure.org/pagure/usage/forks.html
>>
>> Sorry to say that, but I consider this page ill advised. E.g.
>> suggesting
>> to do:
>>
>> ~~~
>>
>> $ git clone ssh://git@pagure.io/forks/jcline/pagure.git
>>
>> ~~~
>>
>> is totally wrong IMO.
> That is most definitively just your opinion :)
>
> I know many people seeing it the other way around. They fork their repo,
> potentially add upstream as another remote, push to their fork, open their
> PR
> and practically will only pull from upstream if upstream asks them to
> rebase or
And that is the major problem with that approach. In this case upstream
has often to tell something to people submitting their PR and just
because the plain "git pull" can't do the right and natural thing.
People then start their branches from obsolete master etc.
AFAIK this is not a problem anymore (as long as upstreams' `master` is `forward-only`,
because GH rebases seamlessly for you.
Pavel
>
> If you clone the upstream repository, then you never have to pull
> anything from your fork. You are using the fork in "push only" mode.
>
> > if they need to do another change.
> >
> >> I would go as far as saying you should never "git
> >> clone" forked repository. You should always "git clone"
the upstream
> >> and
> >> then add the remote for your fork if you need.
> > It's really potato vs potato, clone your fork and add upstream as a remote
> > or
> > clone upstream and add your fork as a remote, at the end what matters is
> > that
> > you know which approach you used (and if you don't git remote -v will tell
> > you)
> > and know how to work with it.
>
> Not really, it is matter of attitude. Clone of upstream is always good
> to have. Just for observing the project or to prepare source tarball or
> whatever else. Fork itself is useless unless you want to contribute.
>
>
> Vít
>
>
10:07 a.m.
----- Original Message -----
From: "Pavel Valena" <pvalena(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Thursday, November 30, 2017 5:02:49 PM
Subject: Re: How to manage a fork
----- Original Message -----
> From: "Vít Ondruch" <vondruch(a)redhat.com>
> To: devel(a)lists.fedoraproject.org
> Sent: Thursday, November 30, 2017 2:55:50 PM
> Subject: Re: How to manage a fork
>
>
>
> Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> > On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
> >> Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
> >>
> >> On 11/29/2017 10:53 AM, Matthew Miller wrote:
> >>
> >> On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
> >>
> >> As as you have a fork, my understanding is that you should just use
> >> traditional gut commands. I’m not aware of a fork being used for much
> >> more than spec PRs.
> >>
> >> Or traditional _git_ commands -- whatever. :)
> >>
> >> Personally, I find that when working with forks of something where
I'm
> >> a casual contributor, I end up doing this a lot:
> >>
> >> git remote add upstream https://pagure.io/fedora-docs/quick-docs
> >>
> >> git fetch upstream
> >> git reset --hard upstream/master
> >>
> >>
> >> (repeat last two steps)
> >>
> >> I'm sure places like github have docs on this too, but pagure also
> >> does:
> >>
> >> https://docs.pagure.org/pagure/usage/forks.html
> >>
> >> Sorry to say that, but I consider this page ill advised. E.g.
> >> suggesting
> >> to do:
> >>
> >> ~~~
> >>
> >> $ git clone ssh://git@pagure.io/forks/jcline/pagure.git
> >>
> >> ~~~
> >>
> >> is totally wrong IMO.
> > That is most definitively just your opinion :)
> >
> > I know many people seeing it the other way around. They fork their repo,
> > potentially add upstream as another remote, push to their fork, open
> > their
> > PR
> > and practically will only pull from upstream if upstream asks them to
> > rebase or
>
> And that is the major problem with that approach. In this case upstream
> has often to tell something to people submitting their PR and just
> because the plain "git pull" can't do the right and natural thing.
> People then start their branches from obsolete master etc.
AFAIK this is not a problem anymore (as long as upstreams' `master` is
`forward-only`, because GH rebases seamlessly for you.
Note that I've not tested this with pagure, but it would make definitely a good RFE.
Pavel
>
> Pavel
>
> >
> > If you clone the upstream repository, then you never have to pull
> > anything from your fork. You are using the fork in "push only" mode.
> >
> > > if they need to do another change.
> > >
> > >> I would go as far as saying you should never "git
> > >> clone" forked repository. You should always "git
clone" the upstream
> > >> and
> > >> then add the remote for your fork if you need.
> > > It's really potato vs potato, clone your fork and add upstream as a
> > > remote
> > > or
> > > clone upstream and add your fork as a remote, at the end what matters is
> > > that
> > > you know which approach you used (and if you don't git remote -v will
> > > tell
> > > you)
> > > and know how to work with it.
> >
> > Not really, it is matter of attitude. Clone of upstream is always good
> > to have. Just for observing the project or to prepare source tarball or
> > whatever else. Fork itself is useless unless you want to contribute.
> >
> >
> > Vít
> >
> >
9:50 a.m.
On 29/11/2017 13:03, Antonio Trande wrote:
Hi all.
I have created a fork on https://src.fedoraproject.org/ but i don't know
how to manage it.
Can i use 'fedpkg'?
Documentation?
Maybe, i was unclear with my question.
If i create a fork of **https://src.fedoraproject.org/rpms/hdf5** like
*https://src.fedoraproject.org/fork/sagitter/rpms/hdf5**, can i use the
fork like it was the original project?
That is, can i push new release with 'fedpkg' or make additional changes
to original RPMs? If not, are they useful for what?
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/
10:05 a.m.
----- Original Message -----
From: "Antonio Trande" <anto.trande(a)gmail.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Thursday, November 30, 2017 4:50:24 PM
Subject: Re: How to manage a fork
On 29/11/2017 13:03, Antonio Trande wrote:
> Hi all.
>
> I have created a fork on https://src.fedoraproject.org/ but i don't know
> how to manage it.
> Can i use 'fedpkg'?
> Documentation?
>
>
Maybe, i was unclear with my question.
If i create a fork of **https://src.fedoraproject.org/rpms/hdf5** like
*https://src.fedoraproject.org/fork/sagitter/rpms/hdf5**, can i use the
fork like it was the original project?
That is, can i push new release with 'fedpkg' or make additional changes
to original RPMs? If not, are they useful for what?
You use them to create pull-requests to the original repo. See
https://docs.pagure.org/pagure/usage/pull_requests.html
Pavel
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.fedoraproject.org/
10:48 a.m.
On Thu, Nov 30, 2017 at 11:05:52AM -0500, Pavel Valena wrote:
> That is, can i push new release with 'fedpkg' or make
additional changes
> to original RPMs? If not, are they useful for what?
You use them to create pull-requests to the original repo. See
https://docs.pagure.org/pagure/usage/pull_requests.html
It'd be pretty awesome to have a button to build in copr from a fork.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2336
days inactive
2337
days old
16 comments
9 participants
participants (9)
-
Antonio Trande -
Brian Exelbierd -
Josh Boyer -
Kevin Fenzi -
Matthew Miller -
Pavel Valena -
Pierre-Yves Chibon -
Todd Zullinger -
Vít Ondruch