Greetings,
It does appear that test/packaging/rpm/cleanup.py is unstable.
I did some investigating and found the following. See red below.
It seems the logic which returns the list of files for inclusion in the
gzipped tarball which is fed to rpmbuild can change the order in the list,
thus when
Russel Winder wrote:
> There was a flurry of activity about potentially switching from
> Mercurial to Git at the beginning of the year. The topic seems to have
> died down. Can I assume that this means Mercurial won the debate and
> that we will not be switching from Mercurial to Git – even
2016-05-12 11:06 GMT+02:00 anatoly techtonik :
> On Fri, May 6, 2016 at 2:18 PM, Alexandre Feblot
> wrote:
> > Hi,
> >
> > Supporting multiple versions at the same time will be required as soon
> as a
> > SCons release breaks compatibility. If you want
Sorry...¨twice as many¨, duh.
Dirk
Am 12. Mai 2016 11:12:19 MESZ, schrieb Dirk Baechle :
>+1 from me for the idea of a git mirror...like this we could have both
>worlds combined. And we would see twice as much contributions as
>before. ;)
>
>Dirk
>
>
>Am 12. Mai 2016 09:27:12
+1 from me for the idea of a git mirror...like this we could have both worlds
combined. And we would see twice as much contributions as before. ;)
Dirk
Am 12. Mai 2016 09:27:12 MESZ, schrieb anatoly techtonik :
>On Mon, May 9, 2016 at 8:13 PM, Bill Deegan
On Fri, May 6, 2016 at 2:18 PM, Alexandre Feblot wrote:
> Hi,
>
> Supporting multiple versions at the same time will be required as soon as a
> SCons release breaks compatibility. If you want your older product sources
> built with an old SCons to keep building, you need to
To sum up my opinion - I am not against going to Git+GitHub, but only
when current repository history is cleaned up of the garbage, such as
DocBook templates and is kept small of that garbage and binary files.
SCons repository size shows that it is untidy mess.
On Mon, May 9, 2016 at 8:13 PM, Bill Deegan wrote:
> All,
>
> So it sounds like (from limited consensus), that switching to Git now, would
> remove a significant barrier to contributing code/fixes?
No. Let's run a Git mirror and see how many fixes will end up there.
HG