2015-01-03 22:56 GMT+01:00 Ruben Van Boxem <[email protected]>: > 2015-01-03 20:44 GMT+01:00 Kai Tietz <[email protected]>: >> >> Yeah, the issue about releasing something not really completing a >> feature is ... well ... feeling bad. Nevertheless I admit that >> already a lot of changes went into master already, and it is obvious >> that our users are eager to get all this in an official released >> version. Additionally it is getting latest with gcc 5.0 pretty >> mandatory to build it with current trunk version due its new '(n)ftw' >> feature. So latest March/April we will need to release trunk IMO. >> But this raises some other questions we need to answer. What happens >> to the already existing open branches? Do we plan do stop maintenance >> at some point for them? Who will tend new branch? Latest thing I >> remember is that JonY agreed to maintain 3.x. So will he agree to do >> this also for upcoming 4.0? >> >> The idea of light release sounds interesting. But what shall we make >> a release criteria then? Time, amount of commits, features, gut >> feeling? > > > This isn't the first time, and probably won't be the last time that other > projects are in need of features in the master branch of MinGW-w64. Perhaps > it would be helpful to revise how new additions are made so that perhaps a > time-based release scheme can be made more feasible and not just "feel bad" > because some stuff isn't finished yet. This would allow for timely releases > of whatever features are finished at a certain point in time without slowing > development for maintenance.
Right, this isn't the first time we have this discussion. And I am in hope it won't be the last time, as things need to change over time, or need at least to be re-thought. My major concern about more complex release mechanism is just the fear to spend our limited resources on administrative subjects and loosing therefore performance on general features. Our developer-resources working regular on mingw-w64 are limited - as far as I can see we have about 4-5 people working regular on our stuff upstream. > It would all depend on how the developers handle this, but here's an idea: > - keep master stable (even more than it is now), merging finished features > and bugfixes only. > - create a staging branch which would contain all new features whenever a > feature developer feels his work is ready enough for tessting. This would > take the place of current master, which contains everything from stable to > unstable commits. > - create true feature branches, which track either staging or master, and > develop each feature in here. Timely merges with staging will allow stuff > like upstream Fedora to keep testing the whole. When finished, a > feature-branch will merge with master, finalizing feature development. Well, to move development to a separate developer-branch is a two-edged bleed. On one hand it is of course a good thing to have the choice of merging (cherry-picking) only wanted features for a new release. So unfinished, or unstable features won't get released that easy to our users. But here is also the disadvantage. A feature not tested will get slower (or even never) fixed. By having multiple developer-branches it might happen that those branch are getting incompatible to each other and so feature-merging gets hard up to impossible. And last but not least it heighten the efforts for our developers. We have limited resources. So spending additional time on maintenance, merging-decisions, separate branch-works, updating branches, etc just slows down our ability to work on new features, on improvements, on giving user-support, ... If we just move development from master to ONE "staging branch", we could limit the issue about incompatible changes on different branches. But well, what is then the difference to work directly on master? If we want to make more detailed decision about what is getting released by new version we can do this also based on prior release-branch, and then cherry-pick changes from master to new release-branch. Nevertheless this is still additional work, and requires some prior discussion. So we would need at least a volunteer taking care about releases, and this should be best not a developer, but a release-manager keeping an eye on things and let the rock roll. Important deeds are for sure starting/answering discussions about releases on ML/IRC, preparing official feature-list of releases (and its documentation), performing releases, and doing advertisement for them, co-ordinate with distributors, and a lot of other things (I miss right now for sure). > In this scheme, master is dead-stable, and releases are only for > distributors to have some form of "latest release". Heck, versioning could > take on a pure incremental scheme (see e.g. systemd), IMHO. I see no reason > why one would want to use an older version anyways. Most native toolchains > are based off of master currently! Well, not sure if master needs to be the stable version ... anyway the idea in general sounds good, but requires additional people willing to spend time and efforts in this. As long as we have too less active developers and no people actually taking care about the releasing itself, I would like to keep additional administrative work away from our developers and stick to work on master. It has shown that it seems to be the most easy variant we can run our development for now. > The only issue I see right now with my suggestion is that staging and master > could diverge a bit, as the former contains a lot of other changes not in > master due to the different features. This will require quite some > discipline from the developers to keep each commit local to where it > belongs. But a normal staging branch which includes all changes isn't an > option, as that is the state of current master. Well, by my experience this "discipline" (as you call it) needs somebody taking care for it. As the most important thing is "keep it simple", "keep it understandable for everybody", and "don't try to press on something unnatural for the common process". As soon as you try to rule against on of those rules you will find you soon in a position of defense and fight, as you need to argue too much. My 2 cents about this, too. Kai > Just my 2 cents. > > Ruben > >> >> Kai >> >> 2015-01-03 15:29 GMT+01:00 Jacek Caban <[email protected]>: >> > On 01/02/15 14:47, Erik van Pienbroek wrote: >> >> It would definitely help us when mingw-w64 would do more frequent >> >> releases. >> > >> > We had a discussion about that in the past, but there was no follow-up. >> > The problem that I can see with past releases that I've been involved in >> > is that there was always a lot of development work just before the >> > release. How about we do an experiment and do a 'light' stable release >> > off the master branch, with no time nor feature pressure. Master branch >> > is pretty stable at this point and contains enough changes to be worth >> > giving it in hands of users. We could just branch at any point soon and >> > release a beta. Depending on how feedback goes, we decide on when to do >> > the final release, but we don't push to have any new development done >> > for the release nor block development on master branch. This should be >> > mostly straightforward. >> > >> > Jacek >> > >> > >> > ------------------------------------------------------------------------------ >> > Dive into the World of Parallel Programming! The Go Parallel Website, >> > sponsored by Intel and developed in partnership with Slashdot Media, is >> > your >> > hub for all things parallel software development, from weekly thought >> > leadership blogs to news, videos, case studies, tutorials and more. Take >> > a >> > look and join the conversation now. http://goparallel.sourceforge.net >> > _______________________________________________ >> > Mingw-w64-public mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net >> _______________________________________________ >> Mingw-w64-public mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
