Re: [Emc-developers] Discuss: patch submissions

[Chris M. <chr...@ho...>]

.
> >
> > 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.
>

ah yes non compilable code is a no no for sure. That is surely a
thing nice about the buildbots - you find out about this quickly. I've
had code work great on my system but breaks on another.
Right now I can push a 'feature' branch to the buildbot to check it
before including it in master - but I have push access.

I should have explained the release manager part better ( only so 
the discussion assumptions are close to reality ).
In my experience here, after a release candidate in branched off,
master is free to be developed. There has been little restriction on what
goes in and no one-person merges work in to it. There is no master manager.

The release manager decides what else gets included in a release candidate.
Usually only bug fixes, sometimes small atomic features can be added, 
eg new components. This is the stability and release phases.
 
The pull request to master is a problem, as we have discussed.
with no master manager or other point of contact, there is no way
to make this happen or find out why it won't or can't happen. If you
have push access you can do things right away, if not .....
Hopefully we can make this situation better as we go.

> > 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).
> 

When I said a test branch, I meant a single branch.
so there would be the current release, master and testing 
in degrees of less stability.

In my mind the difference between master and testing is that testing work
doesn't automatically go into master. Is this how Debain's SID works?
This could backfire too as stuff could get left in testing forever if no one
takes the reins of moving stuff to master.


> > 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 --
> 

Chris Radek is the release manager of 2.4.
My personal feeling is 2.4 should be considered end of life.
Releasing the last bug fixes would be fine (most are actually doc fixes)

Chris M