On Jan 11 2014 3:42 AM, Chris Morley wrote: >> > If it is frozen does that mean UB3 and ja are not being merged in >> > 2.6? >> > Is that official now? >> >> This got me to thinking... What does "official" even mean these >> days. >> Once we have a 1) a branch master, and 2) a plan, Then it makes >> sense >> that it is whatever they decide (and hopefully with some community >> feedback, but they are the one doing the work). >> > > Seb volunteered to be the release manager, he makes the decisions > on what is included or when things are frozen etc. > But if it's not announced on the maillist then it's not official (in > my mind) > The dev maillist is the official correspondence route of the widest > audience.
That makes perfect sense to me. >> The discussion on the meaning of the master branch is good. How >> stable >> master is, is always a good question. My 2c is that it is good to >> keep >> the master as stable as possible with no guarantees -- ie. Do NOT >> commit >> things things that are known to be seriously gefect in the master >> branch >> (that is what special feature and test branches are for), but it is >> still a development branch (the latest and greatest - not guaranteed >> to >> work). > > Well what do you mean by seriously effect master? > If I add code that changes how feed override affects rapids, is that > serious? > I mean it works fine but it seriously changes behaviour. > How about the new TP changes ? It is basically ready for master but > has > actually only been tested by about three people (based on reports)? > No one is commiting code that breaks compiling or function on > purpose. > Everyone has been very good about fixing breakages as soon as we > realize > they are there. But there is only so much testing can be done in a > feature > branch. I think we are in prefect agreement. All I meant is to not commit non-compilable code. But I would argue that this should be a pull operation -- Lets say you have a branch dealing with TP, then you get it working and tested by a couple of people, then you send a pull request to Seb. He then merges it back into master for inclusion and wider distribution and testing. > Right now whatever is put into master is assumed going to be > released. > As others have said maybe we need a branch for testing, that we pick > work from. The nice thing about building testing branches is that it give Seb and all of us a place to work on merging things back and leaves master a little more stable (which I think is a good thing). But it is hard to tell how much work that will cost or save... > if this testing branch is on the buildbot then a wider audience > can / will test. If we can't get people to actual try the testing > branch then > it doesn't really help us. Setting it up on the buildbot is an interesting idea. That would imply that each test branch needs a champion to setup the buildbot, and thwack the code. It would be a little extra work for them, but would save Seb some time if it is agreed that after testing and the pull request comes that the test branch is as close to the current tip of the master as possible (so very few changes necessary). > I'm not sure - just thinking out loud. fair enough. >> I also agree that it is god to keep release branches to >> stabilize and bugfix, but there should be some indication of end of >> life >> for support. How long will 2.4.* and/or 2.5.* be supported once >> 2.6.0 >> comes out? That is roughly how several of the projects I have >> worked >> with did their thing. >> > > Interesting you say that. > 2.4 has about 19 unreleased bug fixes. > The last fix was 19 months ago. > I would say support has ended for it. This needs to be formally decided. Also, if there are only 19 unreleased bug fixes, how much time would it take to release them, and formally put the code to bed. Before doing that we should ask if there is anyone who REALLY needs 2.4, and is willing to commit some resources (time or money) to have it continue to be maintained? EBo -- ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers