Le samedi 16 mai 2020 à 11:09 +0200, Nicolas Mailhot a écrit :
> Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit :
> > So, another way that could work, with minimal tooling is that we
> > keep
> > the master branch strictly mirroring whatever upstream branch we
> > follow,
>
> For
Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit :
>
> So, another way that could work, with minimal tooling is that we
> keep
> the master branch strictly mirroring whatever upstream branch we
> follow,
For some projects we are not hopping between branches of the same
upstream git,
On Thu, 2020-05-14 at 14:30 +0200, Ondřej Lysoněk wrote:
> I was originally excited about source-git, however currently I don't see
> an approach to source-git that would work for me and I don't think I'd
> use it if it became available. And frankly, I think I wouldn't want
> other people using it
clime writes:
> On Thu, 14 May 2020 at 14:31, Ondřej Lysoněk wrote:
>>
>> Hunor Csomortáni writes:
>>
>> > On Wed, May 6, 2020 at 10:24 PM Simo Sorce wrote:
>> >> Well, a way to allow force pushes would be to have a git hook that
>> >> branches the tree before the force push. (creating a
On Thu, 14 May 2020 at 14:31, Ondřej Lysoněk wrote:
>
> Hunor Csomortáni writes:
>
> > On Wed, May 6, 2020 at 10:24 PM Simo Sorce wrote:
> >> Well, a way to allow force pushes would be to have a git hook that
> >> branches the tree before the force push. (creating a branch named
> >> something
Hunor Csomortáni writes:
> On Wed, May 6, 2020 at 10:24 PM Simo Sorce wrote:
>> Well, a way to allow force pushes would be to have a git hook that
>> branches the tree before the force push. (creating a branch named
>> something like audit-force-push-)
>> That way you can retain data for
On Thu, 14 May 2020 at 01:03, Ken Dreyer wrote:
>
> On Wed, May 13, 2020 at 4:29 PM clime wrote:
> > Probably there are more variants but I see these three right now. I
> > think variants 1 and 2 where the spec file is kept in dist-git but
> > patches can be in source-git are more within our
On Wed, May 13, 2020 at 4:29 PM clime wrote:
> Probably there are more variants but I see these three right now. I
> think variants 1 and 2 where the spec file is kept in dist-git but
> patches can be in source-git are more within our reach right now (but
> I might be wrong, variant 3 is also
On Wed, 13 May 2020 at 22:32, Ken Dreyer wrote:
>
> On Tue, May 12, 2020 at 6:20 PM clime wrote:
> > When you do rdopkg new-version and you are asked to force push, is
> > also the current master-patches HEAD tagged with the current package
> > NVR?
>
> It's something that I have to do before I
On Tue, May 12, 2020 at 6:20 PM clime wrote:
> When you do rdopkg new-version and you are asked to force push, is
> also the current master-patches HEAD tagged with the current package
> NVR?
It's something that I have to do before I run "new-version". Here's
the command I ran today:
$ rdopkg
On Wed, May 13, 2020 at 08:16:06AM -0400, Stephen John Smoogen wrote:
> On Wed, 13 May 2020 at 03:19, Florian Weimer wrote:
> >
> > * Stephen John Smoogen:
> >
> > > No because the things that backups and rsync do works in a slow way.
> > > We can do the backup the look-aside cache with tar-balls
On Wed, 13 May 2020 at 03:19, Florian Weimer wrote:
>
> * Stephen John Smoogen:
>
> > No because the things that backups and rsync do works in a slow way.
> > We can do the backup the look-aside cache with tar-balls in a couple
> > of hours. We can also rsync that in the same amount of time. It
* Stephen John Smoogen:
> No because the things that backups and rsync do works in a slow way.
> We can do the backup the look-aside cache with tar-balls in a couple
> of hours. We can also rsync that in the same amount of time. It takes
> that long or longer to do that with a couple of git trees
On Fri, 8 May 2020 at 21:13, David Cantrell wrote:
>
> On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> >Let’s talk about dist-git, as a place where we work. For us,
> >packagers, it’s a well-known place. Yet for newcomers, it may take a
> >while to learn all the details. Even
On Tue, 12 May 2020 at 23:06, Ken Dreyer wrote:
>
> On Tue, May 12, 2020 at 1:45 AM clime wrote:
> >
> > Ken, would it be, please, possible to provide links to the patch
> > branches and mentioned dist-git repos. I would like to have a closer
> > look.
>
> Sure. I can't share the links to the RH
On Tue, May 12, 2020 at 1:45 AM clime wrote:
>
> Ken, would it be, please, possible to provide links to the patch
> branches and mentioned dist-git repos. I would like to have a closer
> look.
Sure. I can't share the links to the RH Ceph Storage dist-git repos,
so I will give one example where I
On Tue, 12 May 2020 at 09:47, Tomas Tomecek wrote:
>
> I haven't responded here for a few days - that doesn't mean I stopped
> caring, quite the opposite, I've read every single response but the
> thread grew so big that I wasn't able to keep up replying.
>
> Given all your valuable feedback, we
I haven't responded here for a few days - that doesn't mean I stopped
caring, quite the opposite, I've read every single response but the
thread grew so big that I wasn't able to keep up replying.
Given all your valuable feedback, we are aiming to come with a plan,
how to provide repositories
On Thu, May 7, 2020 at 3:54 PM clime wrote:
>
>
> > In the rare occasion that I need to make downstream-only changes with
> > patches, I usually just explode the upstream tarball, run "git init",
> > then "git add .", "git commit -m import", apply my changes, and then
> > do "git diff --patch >
On Mon, 11 May 2020 at 18:59, Ken Dreyer wrote:
>
> On Sun, May 10, 2020 at 11:51 PM Petr Pisar wrote:
> > How do you backport fixes? Do apply the fixes directly to dist-git? Or do
> > you
> > apply the fixes to a corresponding patches branch that you occur to have
> > around till needed (e.g.
On Sun, May 10, 2020 at 11:51 PM Petr Pisar wrote:
> How do you backport fixes? Do apply the fixes directly to dist-git? Or do you
> apply the fixes to a corresponding patches branch that you occur to have
> around till needed (e.g. till the hitorical code is supported) for the purpose
> of
On Fri, May 08, 2020 at 09:39:58AM -0600, Ken Dreyer wrote:
> In Ceph we do this at a slightly different point of time. We use
> "rdopkg tag-patches" to save each of the "patches" refs that we've
> translated into patch series in dist-git. Each Git tag is the NVR of
> the package.
>
> We rebase
Hi,
Well, *my* packaging workflow is pretty simple:
1. point to the upstream git repo in my spec file with %{forgeurl} and
the rest of the forge macros
2. point to the target upstream tag or commit with the associated
variable
3. spectool (or co from lookaside if already there)
4. build
If I
On Fri, May 08, 2020 at 10:13:25PM +0200, clime wrote:
> On Fri, 8 May 2020 at 20:05, Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > Hi,
> > I'm a bit late to the party, but here's my 2¢.
> >
> > On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> > > In the packit project, we work in
On Fri, May 08, 2020 at 04:28:37PM -0400, Neal Gompa wrote:
On Fri, May 8, 2020 at 4:25 PM Fabio Valentini wrote:
On Fri, May 8, 2020 at 9:55 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Fri, May 08, 2020 at 03:12:15PM -0400, David Cantrell wrote:
> > WHAT I WANT TO BE ABLE TO DO:
> >
> > *
On Fri, May 08, 2020 at 10:23:45PM +0200, Fabio Valentini wrote:
On Fri, May 8, 2020 at 9:55 PM Zbigniew Jędrzejewski-Szmek
wrote:
On Fri, May 08, 2020 at 03:12:15PM -0400, David Cantrell wrote:
> WHAT I WANT TO BE ABLE TO DO:
>
> * View Fedora's dist-git repos as authoritative for packages
On Fri, May 08, 2020 at 07:54:11PM +, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, May 08, 2020 at 03:12:15PM -0400, David Cantrell wrote:
WHAT I WANT TO BE ABLE TO DO:
* View Fedora's dist-git repos as authoritative for packages built for
Fedora. That is, I want to see a package on my
On Fri, May 8, 2020 at 4:25 PM Fabio Valentini wrote:
>
> On Fri, May 8, 2020 at 9:55 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Fri, May 08, 2020 at 03:12:15PM -0400, David Cantrell wrote:
> > > WHAT I WANT TO BE ABLE TO DO:
> > >
> > > * View Fedora's dist-git repos as authoritative
On Fri, May 8, 2020 at 9:55 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Fri, May 08, 2020 at 03:12:15PM -0400, David Cantrell wrote:
> > WHAT I WANT TO BE ABLE TO DO:
> >
> > * View Fedora's dist-git repos as authoritative for packages built for
> > Fedora. That is, I want to see a package on
On Fri, 8 May 2020 at 20:05, Zbigniew Jędrzejewski-Szmek
wrote:
>
> Hi,
> I'm a bit late to the party, but here's my 2¢.
>
> On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> > In the packit project, we work in source-git repositories. These are
> > pretty much upstream
On Fri, May 08, 2020 at 03:12:15PM -0400, David Cantrell wrote:
> WHAT I WANT TO BE ABLE TO DO:
>
> * View Fedora's dist-git repos as authoritative for packages built for
> Fedora. That is, I want to see a package on my Fedora system and be able to
> visit its dist-git repo to see how it's
On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
Let’s talk about dist-git, as a place where we work. For us,
packagers, it’s a well-known place. Yet for newcomers, it may take a
while to learn all the details. Even though we operate with projects
in a dist-git repository, the
Hi,
I'm a bit late to the party, but here's my 2¢.
On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> In the packit project, we work in source-git repositories. These are
> pretty much upstream repositories combined with Fedora downstream
> packaging files.
I think source-git would
On Wed, May 6, 2020 at 2:24 PM Simo Sorce wrote:
>
> Well, a way to allow force pushes would be to have a git hook that
> branches the tree before the force push. (creating a branch named
> something like audit-force-push-)
In Ceph we do this at a slightly different point of time. We use
"rdopkg
On Wed, May 06, 2020 at 11:41:37AM +0200, Tomas Tomecek wrote:
> I'm actually not a fan of the term "source-git" honestly - I'd love to
> call it "upstream git" since that's what we are trying to do - use the
> repository layout which is well-known in the upstream community.
The problem with that
On Fri, 8 May 2020 at 16:22, Stephen John Smoogen wrote:
>
> On Fri, 8 May 2020 at 09:59, clime wrote:
> >
> > On Thu, 7 May 2020 at 20:58, Kevin Fenzi wrote:
> > >
> > > On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> > > ...snip... please folks... please trim your posts? :)
> > >
> >
On Fri, 8 May 2020 at 09:59, clime wrote:
>
> On Thu, 7 May 2020 at 20:58, Kevin Fenzi wrote:
> >
> > On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> > ...snip... please folks... please trim your posts? :)
> >
> > > These are some great stats!
> > >
> > > But I would like to note that
On Thu, 7 May 2020 at 22:53, clime wrote:
>
>
>
> > In the rare occasion that I need to make downstream-only changes with
> > patches, I usually just explode the upstream tarball, run "git init",
> > then "git add .", "git commit -m import", apply my changes, and then
> > do "git diff --patch >
On Thu, 7 May 2020 at 20:58, Kevin Fenzi wrote:
>
> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> ...snip... please folks... please trim your posts? :)
>
> > These are some great stats!
> >
> > But I would like to note that exploded repos (or source-git repos)
> > have at least two
> In the rare occasion that I need to make downstream-only changes with
> patches, I usually just explode the upstream tarball, run "git init",
> then "git add .", "git commit -m import", apply my changes, and then
> do "git diff --patch > ../00-my-changes.patch" (if it's just one
> commit), or
On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
...snip... please folks... please trim your posts? :)
> These are some great stats!
>
> But I would like to note that exploded repos (or source-git repos)
> have at least two other advantages.
>
> 1) they consume less space than tarballs
On Tue, May 05, 2020 at 03:26:59PM -0400, Robbie Harwood wrote:
> Tomas Tomecek writes:
>
> > Thank you all for raising all the questions and concerns.
> >
> > Before I reply, I'd like to stress that we are still in a prototype
> > phase - not everything is solved (clearly) and at this point, we
Vít Ondruch writes:
> Dne 06. 05. 20 v 20:39 clime napsal(a):
>> On Wed, 6 May 2020 at 13:21, Fabio Valentini wrote:
>>> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch wrote:
Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek wrote:
On Wed, May 6, 2020 at 10:24 PM Simo Sorce wrote:
> Well, a way to allow force pushes would be to have a git hook that
> branches the tree before the force push. (creating a branch named
> something like audit-force-push-)
> That way you can retain data for legal/auditing reasons, while allowing
On Thu, 7 May 2020 at 06:54, clime wrote:
>
> Dne čt 7. kvě 2020 12:19 uživatel Vít Ondruch napsal:
>>
>>
>> Dne 06. 05. 20 v 20:39 clime napsal(a):
>> > On Wed, 6 May 2020 at 13:21, Fabio Valentini wrote:
>> >> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch wrote:
>> >>>
>> >>> Dne 05. 05. 20 v
Dne čt 7. kvě 2020 12:19 uživatel Vít Ondruch napsal:
>
> Dne 06. 05. 20 v 20:39 clime napsal(a):
> > On Wed, 6 May 2020 at 13:21, Fabio Valentini
> wrote:
> >> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch
> wrote:
> >>>
> >>> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> On Mon, May
On 06. 05. 20 11:19, Tomas Tomecek wrote:
On Tue, May 5, 2020 at 6:16 PM Miro Hrončok wrote:
In what way does keeping the spec file in our fork help us?
(speechless for like a minute)
I don't really understand this comment. Speechless because our workflow is
tedious?
I just couldn't
Dne 06. 05. 20 v 20:39 clime napsal(a):
> On Wed, 6 May 2020 at 13:21, Fabio Valentini wrote:
>> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch wrote:
>>>
>>> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek wrote:
Hi Tomas,
* Fabio Valentini:
> In the rare occasion that I need to make downstream-only changes with
> patches, I usually just explode the upstream tarball, run "git init",
> then "git add .", "git commit -m import", apply my changes, and then
> do "git diff --patch > ../00-my-changes.patch" (if it's just
* Pierre-Yves Chibon:
> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
>> But I would like to note that exploded repos (or source-git repos)
>> have at least two other advantages.
>>
>> 1) they consume less space than tarballs for each version because
>> objects in git repo are
On Wed, 2020-05-06 at 20:59 +0200, Pierre-Yves Chibon wrote:
> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> > But I would like to note that exploded repos (or source-git repos)
> > have at least two other advantages.
> >
> > 1) they consume less space than tarballs for each version
On Wed, 6 May 2020 at 21:00, Pierre-Yves Chibon wrote:
>
> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> > But I would like to note that exploded repos (or source-git repos)
> > have at least two other advantages.
> >
> > 1) they consume less space than tarballs for each version
On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> But I would like to note that exploded repos (or source-git repos)
> have at least two other advantages.
>
> 1) they consume less space than tarballs for each version because
> objects in git repo are deduplicated
> 2) instead of
On Wed, 6 May 2020 at 13:21, Fabio Valentini wrote:
>
> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch wrote:
> >
> >
> > Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> > > On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek wrote:
> > >
> > > Hi Tomas,
> > >
> > > I'll respond below with some of my
On Wednesday, May 6, 2020 4:35:11 PM CEST Vít Ondruch wrote:
> I am not concerned about remote branches disappearing. I am concerned
> about the complete opposite, when the remote branches appearing in my
> local copy and not disappearing once the remote copies go.
Isn't this exactly what `git
Dne 06. 05. 20 v 16:15 Robbie Harwood napsal(a):
> Vít Ondruch writes:
>
>> Dne 05. 05. 20 v 21:26 Robbie Harwood napsal(a):
>>> Tomas Tomecek writes:
>>>
Thank you all for raising all the questions and concerns.
Before I reply, I'd like to stress that we are still in a prototype
Vít Ondruch writes:
> Dne 05. 05. 20 v 21:26 Robbie Harwood napsal(a):
>> Tomas Tomecek writes:
>>
>>> Thank you all for raising all the questions and concerns.
>>>
>>> Before I reply, I'd like to stress that we are still in a prototype
>>> phase - not everything is solved (clearly) and at this
Dne 06. 05. 20 v 13:20 Fabio Valentini napsal(a):
> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch wrote:
>>
>> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
>>> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek wrote:
>>>
>>> Hi Tomas,
>>>
>>> I'll respond below with some of my experiences and
Dne 04. 05. 20 v 17:05 Tomas Tomecek napsal(a):
> The main reason I am sending this is to gather feedback from all of
> you whether there is an interest in such a workflow.
I am +1 as long as:
a) this is opt-in (cannot imagine anything else)
b) you resolve the gordic knot of easy sync of changes
Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> So, in my experience, source-git might be a workable solution for
> packages with *big* downstream modifications.
Big +1. Been there, done that (with Tito).
> In the rare occasion that I need to make downstream-only changes with
> patches, I
On Wed, May 6, 2020 at 10:37 AM Vít Ondruch wrote:
>
>
> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> > On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek wrote:
> >
> > Hi Tomas,
> >
> > I'll respond below with some of my experiences and opinions ...
> >
> >> Let’s talk about dist-git, as a
On Wed, May 6, 2020 at 11:31 AM Vít Ondruch wrote:
>
> This is a bit of irony:
>
> ~~~
>
> post-upstream-clone:
> - curl -O
> https://src.fedoraproject.org/rpms/python3/raw/master/f/python3.spec
> - curl -O
> https://src.fedoraproject.org/rpms/python3/raw/master/f/idle3.appdata.xml
> -
On Tue, May 5, 2020 at 7:25 PM Neal Gompa wrote:
>
> Hello Tomas,
>
> I have a fair bit of experience with operating in both so-called
> "source-git" and "dist-git" workflows. I've known them by the names of
> "merged-source" and "split-source" trees respectively, so forgive me
> if I use that
Dne 06. 05. 20 v 11:19 Tomas Tomecek napsal(a):
> On Tue, May 5, 2020 at 6:16 PM Miro Hrončok wrote:
In what way does keeping the spec file in our fork help us?
>>> (speechless for like a minute)
>> I don't really understand this comment. Speechless because our workflow is
>> tedious?
> I
Hi,
Also Fedora is driving a lot of spec syntax enhancements, both at the
rpm and the macro layer. Pushing spec files upstream is a sure way to
freeze spec syntax in stone and have everything behave in rpm 3.x mode
(with rpm 3.x limitations) 20 years from now.
The whole thing is just a variation
On Tue, May 5, 2020 at 6:16 PM Miro Hrončok wrote:
>
> >> In what way does keeping the spec file in our fork help us?
> > (speechless for like a minute)
>
> I don't really understand this comment. Speechless because our workflow is
> tedious?
I just couldn't understand why you are asking me
Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek wrote:
>
> Hi Tomas,
>
> I'll respond below with some of my experiences and opinions ...
>
>> Let’s talk about dist-git, as a place where we work. For us,
>> packagers, it’s a well-known place. Yet
Dne 05. 05. 20 v 18:42 Adam Williamson napsal(a):
> On Tue, 2020-05-05 at 17:45 +0200, Tomas Tomecek wrote:
>> On Tue, May 5, 2020 at 1:41 PM Petr Pisar wrote:
>>> On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
Petr, I should have probably stressed that our target is Fedora
Dne 05. 05. 20 v 21:26 Robbie Harwood napsal(a):
> Tomas Tomecek writes:
>
>> Thank you all for raising all the questions and concerns.
>>
>> Before I reply, I'd like to stress that we are still in a prototype
>> phase - not everything is solved (clearly) and at this point, we
>> experiment with
On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> For some tasks, the workflow is just fine and pretty straightforward.
> But for the other, it’s very gruesome - the moment you need to touch
> patch files, the horror comes in. The fact that we operate with patch
> files, in a git
Tomas Tomecek writes:
> Thank you all for raising all the questions and concerns.
>
> Before I reply, I'd like to stress that we are still in a prototype
> phase - not everything is solved (clearly) and at this point, we
> experiment with the workflow mostly.
>
> Luckily, force-pushes are not
* Neal Gompa:
> On Tue, May 5, 2020 at 1:33 PM Florian Weimer wrote:
>>
>> * Neal Gompa:
>>
>> > In the merged-source world, the packaging is an aspect of managing the
>> > software codebase. This is common in Debian and ALT Linux, where the
>> > standard practice with their tooling is to fork
On Tue, 2020-05-05 at 13:02 -0500, Justin Forbes wrote:
>
> > So when I'm trying to fix an urgent issue in a package that tries to
> > keep its spec file elsewhere, I usually just fix it in dist-git and
> > issue apologies later. I don't see a way this is ever going to not be
> > the case unless
On Tue, May 5, 2020 at 11:43 AM Adam Williamson
wrote:
>
> On Tue, 2020-05-05 at 17:45 +0200, Tomas Tomecek wrote:
> > On Tue, May 5, 2020 at 1:41 PM Petr Pisar wrote:
> > > On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
> > > > Petr, I should have probably stressed that our
Thanks for sharing that, Simo. I respect your opinion.
Believe me, I do like my git history clean and I go to great lengths to
keep it clean. I certainly don't think I'm lazy when it comes to
that. However, I don't think that maintaining a linear history helps
with readability and
On Tue, May 5, 2020 at 1:33 PM Florian Weimer wrote:
>
> * Neal Gompa:
>
> > In the merged-source world, the packaging is an aspect of managing the
> > software codebase. This is common in Debian and ALT Linux, where the
> > standard practice with their tooling is to fork the codebase and
> >
* Neal Gompa:
> In the merged-source world, the packaging is an aspect of managing the
> software codebase. This is common in Debian and ALT Linux, where the
> standard practice with their tooling is to fork the codebase and
> integrate the packaging files into the tree. Changes then are managed
On Mon, May 4, 2020 at 11:06 AM Tomas Tomecek wrote:
>
> Let’s talk about dist-git, as a place where we work. For us,
> packagers, it’s a well-known place. Yet for newcomers, it may take a
> while to learn all the details. Even though we operate with projects
> in a dist-git repository, the
On Tue, May 05, 2020 at 09:42:22AM -0700, Adam Williamson wrote:
> On Tue, 2020-05-05 at 17:45 +0200, Tomas Tomecek wrote:
> > On Tue, May 5, 2020 at 1:41 PM Petr Pisar wrote:
> > > On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
> > > > Petr, I should have probably stressed that
On Tue, 2020-05-05 at 17:45 +0200, Tomas Tomecek wrote:
> On Tue, May 5, 2020 at 1:41 PM Petr Pisar wrote:
> > On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
> > > Petr, I should have probably stressed that our target is Fedora (or
> > > even all Red Hat operating systems). Yes,
On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek wrote:
Hi Tomas,
I'll respond below with some of my experiences and opinions ...
> Let’s talk about dist-git, as a place where we work. For us,
> packagers, it’s a well-known place. Yet for newcomers, it may take a
> while to learn all the details.
On 05. 05. 20 18:12, Tomas Tomecek wrote:
Benefits?
* One works with real source files and not with `SHA512
(nyancat-1.5.2.tar.gz) = 8eee5da8afacdbe8b6b5f6...`
* I can easily pull commits from upstream if needed
* I can also easily propose patches upstream from such a repository
* Updating to
On Tue, May 5, 2020 at 1:04 PM Miro Hrončok wrote:
>
> On 05. 05. 20 12:41, Tomas Tomecek wrote:
> > Before I reply, I'd like to stress that we are still in a prototype
> > phase - not everything is solved (clearly) and at this point, we
> > experiment with the workflow mostly.
>
> Experimenting
On Tue, May 5, 2020 at 1:09 PM clime wrote:
>
> Imho, it would be nice if this could live on src.fp.o in a separate
> dedicated namespace for source repos.
Agreed, that would be ideal!
Tomas
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Tue, May 5, 2020 at 1:41 PM Petr Pisar wrote:
>
> On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
> > Petr, I should have probably stressed that our target is Fedora (or
> > even all Red Hat operating systems). Yes, there are hundreds of
> > distributions and we cannot solve
On Tue, May 5, 2020 at 3:29 PM Ondřej Lysoněk wrote:
> This "rebase all PRs" thing seems to be a recurring theme... What is the
> reason to ask contributors to rebase? (I mean, are we trying to go back
> to the days of centralized version control systems?)
>
> In my experience, there is rarely a
On Tue, May 5, 2020 at 12:13 PM Florian Weimer wrote:
>
> * Tomas Tomecek:
>
> > Florian, a very good point. Yes, we are planning to support GitLab -
> > we have a GSoC project for it:
>
> > https://pagure.io/mentored-projects/issue/69
>
> Is a GSoC project really the appropriate vehicle for
Sorry little reant ahead:
In general, merge commits are hideous, they can conceal merge conflict
resolution that can a) introduce bugs, b) make it hard to figure out
when bugs were introduced by preventing use of git bisect and c)
generally make it very hard to understand the history of changes.
Tomas Tomecek writes:
> Thank you all for raising all the questions and concerns.
>
> Before I reply, I'd like to stress that we are still in a prototype
> phase - not everything is solved (clearly) and at this point, we
> experiment with the workflow mostly.
>
> Luckily, force-pushes are not
On Mon, May 4, 2020, at 11:05 AM, Tomas Tomecek wrote:
> In the packit project, we work in source-git repositories
There's really 3 options:
- dist-git as it exists today (what we thought made sense in the days of CVS
converted into git without much re-engineering)
- source-git (used in
On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
> Petr, I should have probably stressed that our target is Fedora (or
> even all Red Hat operating systems). Yes, there are hundreds of
> distributions and we cannot solve their problems. We are open for
> collaboration though - we
On Tue, 5 May 2020 at 13:06, Miro Hrončok wrote:
>
> On 05. 05. 20 12:41, Tomas Tomecek wrote:
> > Before I reply, I'd like to stress that we are still in a prototype
> > phase - not everything is solved (clearly) and at this point, we
> > experiment with the workflow mostly.
>
> Experimenting is
On 05. 05. 20 12:41, Tomas Tomecek wrote:
Before I reply, I'd like to stress that we are still in a prototype
phase - not everything is solved (clearly) and at this point, we
experiment with the workflow mostly.
Experimenting is cool. Go ahead. As long as this is totally opt-in and does not
Thank you all for raising all the questions and concerns.
Before I reply, I'd like to stress that we are still in a prototype
phase - not everything is solved (clearly) and at this point, we
experiment with the workflow mostly.
Luckily, force-pushes are not allowed in dist-git, which makes the
On Mon, May 4, 2020 at 5:43 PM Richard Shaw wrote:
>
> This may not be related enough to discuss here so I'll take it to another
> thread if needed, but...
>
> One thing that really bugs me is there's still a catch-22. When you're
> working on a new package there is no "git" to work with. I
* Tomas Tomecek:
> Florian, a very good point. Yes, we are planning to support GitLab -
> we have a GSoC project for it:
> https://pagure.io/mentored-projects/issue/69
Is a GSoC project really the appropriate vehicle for this?
Gitlab has one major advantage over Github: it is possible to
Florian, a very good point. Yes, we are planning to support GitLab -
we have a GSoC project for it:
https://pagure.io/mentored-projects/issue/69
On Mon, May 4, 2020 at 6:07 PM Florian Weimer wrote:
>
> * Tomas Tomecek:
>
> > In the packit project, we work in source-git repositories. These are
>
On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> Over the years there have been multiple tools created to improve the
> development experience:
> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
> the way Fedora kernel developers work on kernel [k]).
>
> In
So what is the workflow, how you update to the latest upstream? Or how
you apply custom patch?
Vít
Dne 04. 05. 20 v 17:05 Tomas Tomecek napsal(a):
> Let’s talk about dist-git, as a place where we work. For us,
> packagers, it’s a well-known place. Yet for newcomers, it may take a
> while to
Le lundi 04 mai 2020 à 17:31 +0100, José Abílio Matos a écrit :
> On Monday, 4 May 2020 16.41.26 WEST Richard Shaw wrote:
>
> > For the longest time I at least overrode it so it wouldn't mix
> everything
> > together by putting the package name in the mix: rpmbuild//...
>
> So did I, for the
1 - 100 of 105 matches
Mail list logo
