On Friday, 8 December 2017 10:26:06 UTC+1, Erik Bray wrote: > > On Thu, Dec 7, 2017 at 6:26 PM, William Stein <wst...@gmail.com > <javascript:>> wrote: > > On Thu, Dec 7, 2017 at 7:02 AM, Frédéric Chapoton <fchap...@gmail.com > <javascript:>> wrote: > >> We have currently 115 such positive-reviewed tickets waiting for > inclusion, > > > > Maybe the release manager could use some assistance? Or we could > > rotate to more release managers like we used to do for many years... > > Two things that would be helpful and more like "most" open source > projects (quotes because I have no data to back this up, but from > experience): > > a) Have a normal "bleeding edge" master branch into which all accepted > changes are immediately merged--no waiting (for developers) to get a > development "release" before getting new changes in. > >
The branch could already be programmatically created by a bot based on the positive review status of trac. I think this could be of huge value in terms of seeing wether your code cleanly merges with already positively reviewed code, and for testing purposes as well. However if something like this is done it should be made very clear to everybody to not base any code on this branch (only merge your code with it on a separate branch from time to time to see wether there are merge conflicts and passes all test after the merge). To actually make code get included faster in some branch that at some point will be the next release I think there indeed needs to be some extra "acceptance" mechanism on top of the current positive review one. Since the current positive review does not provide enough guarantees that a ticket is actually good enough that we as a community want to commit to actually get that ticket into the next release, and timely fix the unsuspected blocker tickets it might introduce. I do like the idea of having certain trusted core developers helping to distribute the work of the release manager, but they would have to be really good and trustworthy enough so that they actually save work and not cause extra work and frustration. > b) More people who can merge into master--while it makes sense to have > one "release manager" responsible for keeping a schedule and ensuring > stability of the release (including occasionally putting on hold big > changes that might hold up a release), it also makes sense to have > multiple delegates of approving and merging changes in different areas > of the code, helping to set priorities, and triaging. This can be > entrusted to multiple people with the help of guidelines to make sure > they check all the right boxes when approving a change. For example: > > http://docs.astropy.org/en/stable/development/workflow/maintainer_workflow.html > > <http://www.google.com/url?q=http%3A%2F%2Fdocs.astropy.org%2Fen%2Fstable%2Fdevelopment%2Fworkflow%2Fmaintainer_workflow.html&sa=D&sntz=1&usg=AFQjCNHwNvzh2R6CSDcqQOQc8rki0MZrUw> > > . CPython has a similar document I've seen before, but I can't find > it at the moment, as do many other large projects. I believe Sage > might too... > I also think this blogpost has a very nice description on how to deal with git and different releases: http://nvie.com/posts/a-successful-git-branching-model/ . The develop branch there is playing the role of your "bleeding edge master", and the master branch is only used for official releases. But the underlying principle is the same. There could be some core developers who have right to commit things to the develop aka "bleeding edge master" branch. To make it match also with all the beta's we do the master branch there should maybe split up into a "beta-master" and a "master" branch. With the "beta-master" containing all releases including beta's rc's and the "master" branch just containing the actual releases like 8.0 and 8.1. Depending on how much time it would cost Volker to already start the develop branch for the next release while waiting for the blockers to get fixed in the rc of the current release. Having both of these exist at the same time could solve some of the frustration of things not getting merged. Although I think in a certain sense the not having other things get merged could also be seen as a feature instead of an annoyance, since it provides a good natural incentive for fixing the blockers. That being said, I feel that the people who have actually have been release manager should have a larger say in this then me, since they actually know how it is to do all the hard and dirty work. > > >> see > >> > >> > https://trac.sagemath.org/query?status=positive_review&milestone=!sage-duplicate%2Finvalid%2Fwontfix&group=milestone&col=id&col=summary&col=type&col=component&col=changetime&col=author&col=reviewer&col=dependencies&report=40&desc=1&order=changetime > > >> > >> > >> Le jeudi 7 décembre 2017 15:39:07 UTC+1, Friedrich Wiemer a écrit : > >>> > >>> The ticket #23931 has a positive review for quite some time and I'm > not > >>> aware of any changes left for it, so my humble question is: Is there a > >>> reason this ticket isn't merged yet? > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
