FWIW (maybe not much), a few comments: - msys2 is very useful for me and many others.
- I think a stable repository is *very* helpful, almost required. Many users, such as myself, do not need the latest and greatest. We just need something that works correctly, even if out of date. We are happy with an older stable version. Just like I run a LTS ubuntu release, and only upgrade once every few years. - If the question of how to define a stable repository means which packages to include, I would think someone knowledgeable (not me) would start somewhere, and if someone else thinks another package should be included, then that could be considered. At least whatever is included should be supposed to work correctly for sure. - Maybe I am wrong, but to me a stable repository might mean a point-in-time archived form of msys2 that someone could download and know that it is supposed to work correctly. - I am OK with just downloading everything. I like pacman a lot, but would not mind just downloading a complete stable release. - Obviously, I don't know how to create a msys2 stable repository. I am sure there are many technical details that need to be figured out and automated. I call it a "smoke test" where software can be automatically built at any time to verify it works. I'm sure it takes a lot of work to automate the needed stable repository. Daniel On 2/19/2017 2:08 PM, Mario Emmenlauer wrote: > > Dear MSYS2 users / developers, > > I've start working towards a "stable" repository and would like suggestions! > Please comment! > > > On 21.09.2016 12:04, Mario Emmenlauer wrote: >> On 30.08.2016 13:27, Mario Emmenlauer wrote: >>> On 30.08.2016 13:06, Alexpux wrote: >>>>> 30 авг. 2016 г., в 11:16, Mario Emmenlauer <ma...@emmenlauer.de> >>>>> написал(а): >>>>> >>>>> 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. >>>> >>>> >>>> Hi, Mario! >>>> If someone want to support «stable» repo - we can talk about it. >>>> There are some problem from my POV to support this. >>>> 1. Who will decide that package is stable? >>>> 2. You can’t just copy builded package from current repository and place >>>> it «stable». You must rebuild it agains «stable» set of packages. >>>> 3. Who will maintain all of this work? I will not do any work with this >>>> sorry because my time is limited and now I have many other priorities than >>>> MSYS2. > > 1) Definition of "stable" can mean many things, please provide your thoughts! > In my humble opinion, it would be great if a "stable" repository can fully > build itself. This is my foremost goal. When I started, I picked some ~60 > packages from the repository but I could successfully build only ~30. This > was very frustrating in the beginning. I hope to reduce this pain for new > MSYS2 users. > Currently when toolchain gets updates, its not transparent for me which > packages will get broken and which get fixed. So in my eyes, the first > "stable" release is a toolchain that fully builds itself plus all packages > that cleanly compile and install. Then changes are accepted into "stable" > when (a) they do not break any "stable" package, or (b) all broken > packages > are removed from "stable". So "stable" for me just means "toolchain plus > all packages that compile and install cleanly at that point in time". > > There is a big question in the room: what to do if an update breaks one > package but fixes another? I do not know how to answer. Maybe it is ok > to make a "stable release notifications" via email or twitter before > removing a package from stable, and then users can avoid the update if > they require the to-be-removed package? > > > 2) I have now continuous integration for this task. I'm not an expert, but > got some experience with linux-from-scratch. Please suggest, is the > following a good protocol for checking in intervals of a few days the > "stability" of the build system: > (a) build and install the toolchain-packages that have recent git > changes > (b) build and install all dependencies of the full toolchain > (c) build and install the full toolchain (not just changed packages) > (d) build and install all "stable" packages (including all toolchain > dependencies and full toolchain) > (e) try to build more packages from the archive which are not stable > > If (d) is successful, then the latest git should be safe for "stable". > If (e) is successful then more packages can come into "stable". If (d) > is not reached, then a decision must be taken if the broken packages > will be removed from "stable" or will be fixed. > Is this a good protocol? The toolchain is rebuilt up to 3 times in this > process to be 150% sure it is "cleanly" compiled only against newest > dependencies. > > > 3) I have automated task (2) with my CI system. So I can regularly (weekly, > and by request?) test the latest snapshot for stability. I can also send > emails about current status, and my build logs are public. But it would > still be up to the developers to act upon this knowledge. I will also > try to help with maintaining the "stable" state, but I also do not have > much time. > > Would this be helpful? > > Cheers, > > Mario > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
