Dear Daniel,
thanks for the thumbs up! See below for more:
On 05.06.2017 23:59, Daniel Goldman wrote:
> I really appreciate the work you are doing.
>
> Could you clarify difference between 'stable' and 'testing'? I thought
> 'stable' means 'archived release' and guarantees that everything works, and
> 'testing'
> means 'development release' and perhaps includes new things not guaranteed to
> work. 'stable' and 'testing' do not seem synonyms to me. I could be totally
> mixed
> up about this.
>
> IMO, having a system that someone can download and know will work correctly,
> if that is possible, seems pretty useful.
There was some discussion about this topic in autumn 2016. When I
started using MSYS2 and the MINGW-packages git repo, I instantly fell
in love! Its by far the best effort on Windows software development
I've seen so far. But at the time, I experienced quite often that
packages failed to build. It could very well happen that the version
of a package X that was included in the repo could not be compiled
with the current snapshot of the repo. I find this a fair policy of
the "release fast and release often" policy. But it made my life
quite difficult whenever I needed to modify an MSYS2 package - there
was a good chance I would not be able to build my changes :-)
Since then, I've come to realize that the term "stable" has quite a
different meaning to different people. In Debian terminology, stable
is something that builds, tests, and is proven by a large number of
real-world users for a long time. What I try to achieve with my
effort is exclusively the following:
- to have a well-defined snapshot of packages in specific versions
- where all included packages guarantee to build against themselves,
- where all prerequisite packages of included packages are also
included, and
- where all enabled tests work, if any
So with that snapshot, you can be certain that you can recompile any
included package over and over, and the build should never fail. And
you can rebuild all prerequisites too. Additionally, I run a triple
bootstrap procedure: first the full toolchain is rebuild with the last
stable toolchain, then the full toolchain is rebuild with itself, and
then all packages are rebuild with the new toolchain. So all packages
will use the same headers, same gcc version, etc.
I would like to stress one important thing: My intention is that the
above testing procedure will identify build-issues in package inter-
dependencies that the current CI system does not pick up. I will report
those issues upstream and try to aid in fixing them (as much as time
permits). With this additional level of testing I hope that MSYS2
becomes more stable, and my binary repository is not needed at all!
Producing binaries is just a side effect of my CI effort, and not my
goal. My preferred outcome is to have procedures in place that allow
to flag breakages in the git repo early on, so they can be fixed
directly at the source.
All the best,
Mario
> I can only speak for myself. I find msys2 quite useful. I mainly need
> something that works correctly, not necessarily the newest version of
> everything. I
> installed msys2 several years ago. Aside from a few non-fatal glitches that I
> reported, everything has worked fine, and I have not attempted to do any
> updates.
>
> Daniel
>
> On 6/5/2017 8:12 AM, Mario Emmenlauer wrote:
>>
>> Dear All,
>>
>> I just wanted to let you know that I have not given up on the idea
>> of a stable (better named "testing") repository for MSYS2. My goal
>> is to have in regular, short intervals a fully bootstrapped rebuild
>> of all MSYS2 MinGW packages (based on a current whitelist). With
>> this effort I will try to isolate packages that are broken in such a
>> way that the current CI does not pick up. I.e. the current CI tests
>> that any package X will build correctly. But it does not test that
>> other packages depending on X still build against the updated X.
>> My CI will do this. The cost is a much longer build time. So instead
>> of triggering builds by commit, I will trigger builds with a timer.
>> The current build interval is ~30hrs, but this may go up significantly
>> with a growing whitelist.
>>
>>
>> So in the past six months I set up the build system with dependency
>> tracking. Its not perfect but it should be quite ok. In 99.9% of the
>> cases I can identify the list of all recursive dependencies of an
>> MSYS2 MinGW package. I also have a small whitelist set up from which
>> I will start. Since a few months all this is working on a subset of
>> packages.
>>
>> But in my whitelist, I'd like to include Qt and VTK since both are
>> very relevant for me. And I'd like to make a release only when *all*
>> included packages can be successfully compiled against themselves. So
>> any failing package from the whitelist or the recursive prerequisites
>> is a blocker. As of now I can still not build mingw-w64-SDL2, mingw-
>> w64-icu and mingw-w64-firebird2-git. I've reported the SDL2-issue
>> upstream a long while ago and the problem is isolated, but the fix
>> is not in yet. icu is undergoing a discussion as I am writing this
>> email. And firebird2 is broken since more than six months but it has
>> not received too much attention yet.
>>
>>
>> Cutting a long story short: hopefully soon there should be fixes for
>> the three missing packages, and then I can make a first "testing"
>> release. From there I'd like to gather user feedback. I'd also like to
>> gather requests for further whitelisted packages.
>>
>> All the best,
>>
>> Mario
>>
>>
>>
>> On 30.08.2016 10:16, Mario Emmenlauer wrote:
>>>
>>> I was wondering if people would like to have a "stable" repository?
>>>
>>> I was thinking that when a plateau is reached (majority of packages
>>> compiles fine), the current snapshot could be copied to stable. In my
>>> eyes, the essential requirement would be that all base packages compile
>>> fine. Everything else could be handled a bit ad-hoc.
>>>
>>> All the best, Mario
>>>
Viele Gruesse,
Mario Emmenlauer
--
BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203
Balanstr. 43 mailto: memmenlauer * biodataanalysis.de
D-81669 München http://www.biodataanalysis.de/
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Msys2-users mailing list
Msys2-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/msys2-users
