On Sun, 2012-05-20 at 20:02 -0400, Paul Wouters wrote:
> On Fri, 18 May 2012, Richard W.M. Jones wrote:
>
> > On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> >> And definitvely, for me, (and probably only for me), git is really
> >> not a good tool for spec maintenance.
> >
> > Not
On Thu, May 24, 2012 at 11:15:38AM +0200, Thomas Spura wrote:
> On Thu, May 24, 2012 at 11:02 AM, Stanislav Ochotnicky
> wrote:
> > * If a git commit is tagged in a specific way, omit from rpm changelog.
> > What I mean by "tagged" is a git tag, in form of let's say
> > "silentXXX". Where XXX
On Thu, May 24, 2012 at 11:02 AM, Stanislav Ochotnicky
wrote:
> * If a git commit is tagged in a specific way, omit from rpm changelog.
> What I mean by "tagged" is a git tag, in form of let's say
> "silentXXX". Where XXX has to be unique, but that can be figured out by
> fedpkg easily.
I'
On 05/23/2012 06:30 PM, Jesse Keating wrote:
On 05/22/2012 11:53 PM, Panu Matilainen wrote:
Well, here's what I see after drop_caches=3 from 'strace -tt fedpkg
verrel' on kernel.spec which is one of the most complicated specs in
Fedora land:
09:09:06.928011 fedpkg exec
09:09:12.699345 python im
Quoting Paul Wouters (2012-05-21 02:02:23)
> On Fri, 18 May 2012, Richard W.M. Jones wrote:
>
> > On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> >> And definitvely, for me, (and probably only for me), git is really
> >> not a good tool for spec maintenance.
> >
> > Not duplicating
On 05/22/2012 11:53 PM, Panu Matilainen wrote:
Well, here's what I see after drop_caches=3 from 'strace -tt fedpkg
verrel' on kernel.spec which is one of the most complicated specs in
Fedora land:
09:09:06.928011 fedpkg exec
09:09:12.699345 python imports done
09:09:13.510192
On 05/23/2012 02:12 AM, Jesse Keating wrote:
On 05/22/2012 12:33 AM, Jan Kratochvil wrote:
True, I agree now. It is just so slow (0m2.693s now, 0m4.222s with
drop_caches=3) I expected it waits for network.
Just out of curiosity, which package is that? I'm seeing a much bigger
difference betwe
On 05/22/2012 12:33 AM, Jan Kratochvil wrote:
True, I agree now. It is just so slow (0m2.693s now, 0m4.222s with
drop_caches=3) I expected it waits for network.
I bet if you traced it, the majority of time is waiting for rpm to
return queries about the spec file.
--
jlk
--
devel mailing lis
On 05/20/2012 09:49 PM, Matthew Miller wrote:
On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote:
Agreed. changelog and version field conflicts are 90% of my cherry-pick
conflicts.
I would be in favour of no longer maintaining a changelog in the spec file
As long as it gets put into
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 21 May 2012 09:50:53 -0700
Jesse Keating wrote:
> On 05/21/2012 08:34 AM, Matej Cepl wrote:
> >
> > I give you that, but do you see any alternative which would in
> > let's say five years replaced git in Fedora? Five years is a long
> > time
On Tue, May 22, 2012 at 09:07:56AM +0100, Richard W.M. Jones wrote:
> On Mon, May 21, 2012 at 10:13:41AM -0400, David Cantrell wrote:
> > We automatically generate the spec file changelog block each time we make a
> > new release of anaconda. Check out scripts/makebumpver in the anaconda git
> > r
On Mon, May 21, 2012 at 3:08 PM, Kevin Kofler wrote:
> Greg Swift wrote:
>> i'm not against cleaning up ifs related to end of life/support
>> releases, but how far are you suggesting that go?
>
> All support for Fedora n should be dropped at Fedora n's end of life.
which fits within the definitio
Dne 22.5.2012 13:52, Ralf Corsepius napsal(a):
On 05/22/2012 01:42 PM, Vít Ondruch wrote:
Dne 22.5.2012 13:22, Stanislav Ochotnicky napsal(a):
I never
use clog for creating changelog in spec so I don't know how it's
supposed to work. I assume it stopped working right after cvs->fedpkg
transit
On 05/22/2012 01:42 PM, Vít Ondruch wrote:
Dne 22.5.2012 13:22, Stanislav Ochotnicky napsal(a):
I never
use clog for creating changelog in spec so I don't know how it's
supposed to work. I assume it stopped working right after cvs->fedpkg
transition.
Neither did I and I don't think it is eve
Dne 22.5.2012 13:22, Stanislav Ochotnicky napsal(a):
Quoting Vít Ondruch (2012-05-22 10:01:06)
Dne 21.5.2012 18:47, Stanislav Ochotnicky napsal(a):
Quoting Ralf Corsepius (2012-05-21 17:13:56)
On 05/21/2012 12:09 PM, Matej Cepl wrote:
On 21.5.2012 10:23, Ralf Corsepius wrote:
-1 changelogs a
Quoting Vít Ondruch (2012-05-22 10:01:06)
> Dne 21.5.2012 18:47, Stanislav Ochotnicky napsal(a):
> > Quoting Ralf Corsepius (2012-05-21 17:13:56)
> >> On 05/21/2012 12:09 PM, Matej Cepl wrote:
> >>> On 21.5.2012 10:23, Ralf Corsepius wrote:
> -1 changelogs are manually written documents and so
On Mon, May 21, 2012 at 10:13:41AM -0400, David Cantrell wrote:
> We automatically generate the spec file changelog block each time we make a
> new release of anaconda. Check out scripts/makebumpver in the anaconda git
> repo on git.fedorahosted.org.
>
> For us, the work is done in git.fedorahost
Dne 21.5.2012 18:47, Stanislav Ochotnicky napsal(a):
Quoting Ralf Corsepius (2012-05-21 17:13:56)
On 05/21/2012 12:09 PM, Matej Cepl wrote:
On 21.5.2012 10:23, Ralf Corsepius wrote:
-1 changelogs are manually written documents and source files.
And your commit messages are written by aliens?
On Tue, 22 May 2012 06:23:56 +0200, Jesse Keating wrote:
> > So that the NVR<-> hash mapping needs to be done by 'fedpkg verrel' which
> > (a) requires network connectivity contradicting GIT local repo, (b) is slow.
>
> Hrm, in what way does it require network connectivity? gitbuildhash
> does r
On Mon, 2012-05-21 at 21:58 +0200, Kevin Kofler wrote:
> Tom Lane wrote:
> > [ shrug... ] The fact that *you* don't care is not evidence that nobody
> > else cares, and it is certainly not evidence that nobody else should care.
>
> The fact that many maintainers have been doing this for years an
On 05/21/2012 08:17 PM, Jan Kratochvil wrote:
On Mon, 21 May 2012 18:47:05 +0200, Stanislav Ochotnicky wrote:
i.e. there was no empty line so git chucked them all into subject when
generating mails. Now they do:
"line one
- line two
- line three"
There is primarily missing the first line:
* M
On Mon, 21 May 2012 18:47:05 +0200, Stanislav Ochotnicky wrote:
> i.e. there was no empty line so git chucked them all into subject when
> generating mails. Now they do:
> "line one
>
> - line two
> - line three"
There is primarily missing the first line:
* Mon May 14 2012 Jan Kratochvil -
7.4.
On Seg, 2012-05-21 at 14:49 +0100, Sérgio Basto wrote:
> I just begin with better documentation, git "guide lines" are in the
> end
> of something that doesn't look git docs.
>
I mean, *better* documentation please .
$ git checkout master (or fedpkg switch-branch)
... do a fix, test, commit, bui
On 05/21/2012 01:51 PM, Simo Sorce wrote:
> re-writing history in a shared git repo is quite rude to all the people
> who have it cloned. Not something I'm going to support.
Nothing that can't be easily solved by a git pull --rebase most of the
time.
It's still not a path I would want to go
On Mon, 2012-05-21 at 09:48 -0700, Jesse Keating wrote:
> On 05/21/2012 06:08 AM, Thomas Moschny wrote:
> > 2012/5/21 Simo Sorce:
> >> Except we do not allow to rewrite history and push -f so you will never
> >> be able to squash everything.
> >
> > If koji/bodhi were able to tag successful builds
Ralf Corsepius wrote:
> I usually write them once:
> *.spec
> fedpkg clog
> fedpkg commit -F clog -p
I also write the logs in the specfile first, but then I middle-click-paste
them into git-cola's commit message textbox.
Am I the only one using git-cola for Fedora dist-git? IMHO, it's much more
Greg Swift wrote:
> i'm not against cleaning up ifs related to end of life/support
> releases, but how far are you suggesting that go?
All support for Fedora n should be dropped at Fedora n's end of life.
> I know that I've pulled plenty of rawhide packages for build on a RHEL box
> when necessar
Tom Lane wrote:
> [ shrug... ] The fact that *you* don't care is not evidence that nobody
> else cares, and it is certainly not evidence that nobody else should care.
The fact that many maintainers have been doing this for years and nobody
complained about it is, though.
It just doesn't make se
On Mon, 2012-05-21 at 12:21 +0200, Gerd Hoffmann wrote:
> On 05/21/12 10:23, Ralf Corsepius wrote:
> > On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
> >> - Original Message -
> >>> On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> And definitvely, for me, (and probably on
On 05/21/2012 08:34 AM, Matej Cepl wrote:
I give you that, but do you see any alternative which would in let's say
five years replaced git in Fedora? Five years is a long time in computer
industry, but OTOH five years ago (plus how long it has been since we
actually switched to git) it was IMHO
On 05/21/2012 06:08 AM, Thomas Moschny wrote:
2012/5/21 Simo Sorce:
Except we do not allow to rewrite history and push -f so you will never
be able to squash everything.
If koji/bodhi were able to tag successful builds within git, we would
be able to allow rewrites, squash commits and the like
Quoting Ralf Corsepius (2012-05-21 17:13:56)
> On 05/21/2012 12:09 PM, Matej Cepl wrote:
> > On 21.5.2012 10:23, Ralf Corsepius wrote:
> >> -1 changelogs are manually written documents and source files.
> >
> > And your commit messages are written by aliens?
> My change logs are inside of the rpm.s
Le lundi 21 mai 2012 à 09:01 -0700, Adam Williamson a écrit :
> On Mon, 2012-05-21 at 08:33 +0100, Richard W.M. Jones wrote:
> > On Sun, May 20, 2012 at 09:49:03PM -0400, Matthew Miller wrote:
> > > On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote:
> > > > Agreed. changelog and version
On Mon, 2012-05-21 at 08:33 +0100, Richard W.M. Jones wrote:
> On Sun, May 20, 2012 at 09:49:03PM -0400, Matthew Miller wrote:
> > On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote:
> > > Agreed. changelog and version field conflicts are 90% of my cherry-pick
> > > conflicts.
> > > I wou
On 21.5.2012 17:13, Ralf Corsepius wrote:
... nobody mentioned Bodhi update messages here).
I did not want to reheat previous discussions on Fedora bureaucracy, but
this is part of it.
I wouldn't dare say a word about our update policy (Growing up in the
Communist Czechoslovakia taught me whe
On 05/21/2012 12:09 PM, Matej Cepl wrote:
On 21.5.2012 10:23, Ralf Corsepius wrote:
-1 changelogs are manually written documents and source files.
And your commit messages are written by aliens?
My change logs are inside of the rpm.spec.
You are lucky! I have to
write them myself (and I re
Greg Swift venit, vidit, dixit 21.05.2012 15:29:
> On Mon, May 21, 2012 at 4:52 AM, Michael J Gruber
> wrote:
>> * put compatibility cludges for older releases on their respective
>> branches (this gets rid of many if's in spec)
>
> i'm not against cleaning up ifs related to end of life/support
>
Stanislav Ochotnicky venit, vidit, dixit 21.05.2012 14:49:
> Quoting Michael J Gruber (2012-05-21 11:52:40)
>> Sérgio Basto venit, vidit, dixit 18.05.2012 22:25:
>>> On Sex, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote:
I've been seeing this ugliness more and more to the point where
Karel Zak venit, vidit, dixit 21.05.2012 12:43:
> On Mon, May 21, 2012 at 11:52:40AM +0200, Michael J Gruber wrote:
>> Just like we have mandatory packaging guidelines, we should have
>> mandatory git guidelines simply because it is part of the build system,
>
> yep, and also mailing list guideli
On Mon, May 21, 2012 at 06:27:38AM -0400, Jaroslav Reznik wrote:
> - Original Message -
> > On Mon, 2012-05-21 at 10:23 +0200, Ralf Corsepius wrote:
> > > On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
> > > > - Original Message -
> > > >> On Fri, May 18, 2012 at 07:07:56PM +0200, R
On Seg, 2012-05-21 at 12:43 +0200, Karel Zak wrote:
> On Mon, May 21, 2012 at 11:52:40AM +0200, Michael J Gruber wrote:
> > Just like we have mandatory packaging guidelines, we should have
> > mandatory git guidelines simply because it is part of the build system,
>
> yep, and also mailing list
On Mon, May 21, 2012 at 4:52 AM, Michael J Gruber
wrote:
> * put compatibility cludges for older releases on their respective
> branches (this gets rid of many if's in spec)
i'm not against cleaning up ifs related to end of life/support
releases, but how far are you suggesting that go? I know th
2012/5/21 Simo Sorce :
> Except we do not allow to rewrite history and push -f so you will never
> be able to squash everything.
If koji/bodhi were able to tag successful builds within git, we would
be able to allow rewrites, squash commits and the like at least for
commits that never have been su
On Mon, 2012-05-21 at 14:21 +0200, Emanuel Rietveld wrote:
> On 05/21/2012 01:56 PM, Ralf Corsepius wrote:
> > Technically, the major difference is git recording each and every
> > detail, which an rpm's user hardly is interested in. The latter audience
> > is not interested in seeing these details
Dne 21.5.2012 12:09, Matej Cepl napsal(a):
On 21.5.2012 10:23, Ralf Corsepius wrote:
-1 changelogs are manually written documents and source files.
And your commit messages are written by aliens? You are lucky! I have
to write them myself (and I really hate that I have to write the same
info
Quoting Michael J Gruber (2012-05-21 11:52:40)
> Sérgio Basto venit, vidit, dixit 18.05.2012 22:25:
> > On Sex, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote:
> >> I've been seeing this ugliness more and more to the point where I just
> >> can't keep writing individual emails. Repeat after
On 05/21/2012 02:19 PM, Stijn Hoop wrote:
The reasons you mention are just FUD -- this can happen to whatever
data you specify
No ... I have seen all such cases happen.
People killing git histories in various ways, ... not worth mentioning,
I'd yet have to see one single VCS conversion which d
On 05/21/2012 01:56 PM, Ralf Corsepius wrote:
Technically, the major difference is git recording each and every
detail, which an rpm's user hardly is interested in. The latter audience
is not interested in seeing these details, they are interesting in
"summaries".
E.g. they are not interested in
On Mon, 21 May 2012 13:40:55 +0200
Ralf Corsepius wrote:
> On 05/21/2012 12:21 PM, Gerd Hoffmann wrote:
> > On 05/21/12 10:23, Ralf Corsepius wrote:
> >> On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
> >>> - Original Message -
> On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet w
On 05/21/2012 12:27 PM, Jaroslav Reznik wrote:
- Original Message -
On Mon, 2012-05-21 at 10:23 +0200, Ralf Corsepius wrote:
On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
- Original Message -
On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
And definitvely, for m
On 05/21/2012 12:21 PM, Gerd Hoffmann wrote:
On 05/21/12 10:23, Ralf Corsepius wrote:
On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
- Original Message -
On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
And definitvely, for me, (and probably only for me), git is really
not
On Mon, 2012-05-21 at 12:43 +0200, Karel Zak wrote:
> On Mon, May 21, 2012 at 11:52:40AM +0200, Michael J Gruber wrote:
> > Just like we have mandatory packaging guidelines, we should have
> > mandatory git guidelines simply because it is part of the build system,
>
> yep, and also mailing list g
On Mon, May 21, 2012 at 11:52:40AM +0200, Michael J Gruber wrote:
> Just like we have mandatory packaging guidelines, we should have
> mandatory git guidelines simply because it is part of the build system,
yep, and also mailing list guidelines, bugzilla guidelines and
finally fashion police...
- Original Message -
> On Mon, 2012-05-21 at 10:23 +0200, Ralf Corsepius wrote:
> > On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
> > > - Original Message -
> > >> On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> > >>> And definitvely, for me, (and probably only for m
On 05/21/12 10:23, Ralf Corsepius wrote:
> On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
>> - Original Message -
>>> On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
And definitvely, for me, (and probably only for me), git is really
not a good tool for spec maintenanc
On 21.5.2012 10:23, Ralf Corsepius wrote:
-1 changelogs are manually written documents and source files.
And your commit messages are written by aliens? You are lucky! I have to
write them myself (and I really hate that I have to write the same
information thrice ... nobody mentioned Bodhi up
On Mon, 2012-05-21 at 10:23 +0200, Ralf Corsepius wrote:
> On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
> > - Original Message -
> >> On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> >>> And definitvely, for me, (and probably only for me), git is really
> >>> not a good tool
Sérgio Basto venit, vidit, dixit 18.05.2012 22:25:
> On Sex, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote:
>> I've been seeing this ugliness more and more to the point where I just
>> can't keep writing individual emails. Repeat after me: git is not CVS.
>>
>> When you have 2 branches wit
On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
- Original Message -
On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
And definitvely, for me, (and probably only for me), git is really
not a good tool for spec maintenance.
Not duplicating the changelog would help. There's
- Original Message -
> On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> > And definitvely, for me, (and probably only for me), git is really
> > not a good tool for spec maintenance.
>
> Not duplicating the changelog would help. There's little reason to
> have a changelog in
On Sun, May 20, 2012 at 09:49:03PM -0400, Matthew Miller wrote:
> On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote:
> > Agreed. changelog and version field conflicts are 90% of my cherry-pick
> > conflicts.
> > I would be in favour of no longer maintaining a changelog in the spec file
>
On Sun, 20 May 2012, Matthew Miller wrote:
On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote:
Agreed. changelog and version field conflicts are 90% of my cherry-pick
conflicts.
I would be in favour of no longer maintaining a changelog in the spec file
As long as it gets put into th
On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote:
> Agreed. changelog and version field conflicts are 90% of my cherry-pick
> conflicts.
> I would be in favour of no longer maintaining a changelog in the spec file
As long as it gets put into the final RPM in the build process somehow.
On Fri, 18 May 2012, Richard W.M. Jones wrote:
On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
And definitvely, for me, (and probably only for me), git is really
not a good tool for spec maintenance.
Not duplicating the changelog would help. There's little reason to
have a chang
Kevin Kofler writes:
> Remi Collet wrote:
>> For me, the %changelog "must" stay branch specific.
>> p.e, I don't want the f16 branch polluted by "mass rebuild" entry from
>> rawhide.
> You're just too pedantic about that. I stopped caring about this issue eons
> ago, even in CVS days, where I'd
Remi Collet wrote:
> For me, the %changelog "must" stay branch specific.
> p.e, I don't want the f16 branch polluted by "mass rebuild" entry from
> rawhide.
You're just too pedantic about that. I stopped caring about this issue eons
ago, even in CVS days, where I'd just "sync from devel", i.e. ov
Simo Sorce wrote:
> This is really a personal preference.
> For example I really *hate* merges, they clutter everything.
They don't clutter anything at all if they're fast-forward. If you're going
to push the same new version to all releases (as was done in the
screenshot), I see no reason not t
On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> And definitvely, for me, (and probably only for me), git is really
> not a good tool for spec maintenance.
Not duplicating the changelog would help. There's little reason to
have a changelog in git which is then manually copied into %
On Sex, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote:
> I've been seeing this ugliness more and more to the point where I just
> can't keep writing individual emails. Repeat after me: git is not CVS.
>
> When you have 2 branches with identical content and history (typically
> right after
On Fri, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote:
> I've been seeing this ugliness more and more to the point where I just
> can't keep writing individual emails. Repeat after me: git is not CVS.
>
> When you have 2 branches with identical content and history (typically
> right after
Le 18/05/2012 18:35, Stanislav Ochotnicky a écrit :
So please. Merge as long as it makes sense (i.e. unless something needs
to be changed specifically in one branch).
Sorry but, I think, in most of the case "merge" is not the solution.
For me, the %changelog "must" stay branch specific.
p.e,
I've been seeing this ugliness more and more to the point where I just
can't keep writing individual emails. Repeat after me: git is not CVS.
When you have 2 branches with identical content and history (typically
right after branching or when the maintainer is updating all releases
together) then
72 matches
Mail list logo
