Originally posted by Weasel
View Post
There was a change over 7 years ago in the testbot when it stopped checking each individual git entry.
Notice its doing a run every day most of the time. Sometimes you will have 2 runs per day and others no runs per day. The validation is checking patches in groups. Yes if you pull the latest git version this is not the latest version validated by testbot you risk getting a version with half a patch set applied.
Yes you have people come into #winehq on freenode who have thought that could do what you said ask us about hey I built this master branch version of wine its not working right and we look at the testbot and patches applied and tell them hey it does work because what you have was taken in the middle of a patch set.
So you do not with wine direct user to download latest git version. Instead you first direct them to a develop release that is that is about every 2 weeks or to a version that went well in testbot because you know those numbers are patch set complete.
Now when you get projects without automatic CI like wine testbot and they are not doing releases and tell you to pull master from git is fairly much play a game of chance sooner or latter you will roll up half a patch set and want you downloaded fails to work correctly.
Its not that hard to set a time frame to tag releases so you end users can download items all the time that are patch set complete.
Users don't want the latest commits. Users want the latest point that works. Latest commits equals possible being half a patch-set so a program that does not work. Tagging releases is means to tell Users where the latest point that works is. If you are not doing a release you need list somewhere of git release numbers that are patchset complete then people packaging will use that as a release version number so you really did a release anyhow.
Originally posted by Weasel
View Post
Nothing like being a clueless wonder. Every 2 weeks roughly due to the rough 2-4 week development cycle the items on the patch que will be ticked off as accepted or answered as not accepted and why. Basically its like the Linux kernel 2 week merge window except it never closes except for the stable qa timeframe. So with the linux kernel roughly 90 days you get 2weeks to submit you patches and find out if they will be accepted or not.
This is something you start seeing a lot. Large number of patches people work on and not submit until they can get an answer in 2 weeks if it will be acceptable or not.
Stable release is a time wine project put aside every 12 months to stop and do more in depth quality control.
The release cycle of wine has been designed to suit end users by giving them releases quickly also to maintain a fast cycle in patch processing.
If you know you only have less than 14 days to approve something you make you choices quickly. If you know you have 12 months you suffer from procrastinate on making choice badly. 90 days of project leader procrastination or you worrying if they will accept you patch or not is bad enough. Shorter project leader procrastination time the better.
Long release cycles have habit of letting project leaders suffer from procrastination and developers stressing over their patches as the project leaders do their procrastination over if this patch is good enough. Its a lot better with a short release cycle and get the pain over quickly.
Really long release cycles don't help development and is not that helpful to end users having issues so in need of newer version.
ABI stability and release cycles are two different things. There are ways of ensuring ABI stability and do a release every single day.
There worst part about lead developer procrastination being allowed to run too long is by the time a person finds out that their patch is not accepted they can be working for another company that no longer wants them working on that patch. That patch could be a new feature or fix a security flaw.
Comment