release 3.4.x

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

release 3.4.x

Jaroslav Hajek-2
hi all,

what about forking the 3-4-x branch now, and start making release candidates?
Thomas, would you be willing to host 3.4.x on hg.tw-math.de?

regards

--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

David Bateman
Jaroslav Hajek-2 wrote
hi all,

what about forking the 3-4-x branch now, and start making release candidates?
Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
Shouldn't the fltk legends be included before the fork?

D.
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

Jaroslav Hajek-2
On Wed, Sep 8, 2010 at 11:18 AM, David Bateman <[hidden email]> wrote:

>
>
> Jaroslav Hajek-2 wrote:
>>
>> hi all,
>>
>> what about forking the 3-4-x branch now, and start making release
>> candidates?
>> Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
>>
>
> Shouldn't the fltk legends be included before the fork?
>
> D.
>

Don't know about "should". Are they close to being finished? In any
case, I most likely won't be able to do the release after October
begins. So if it's not started now, someone else will have to do it.


--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

bpabbott
Administrator
In reply to this post by David Bateman
On Sep 8, 2010, at 5:18 AM, David Bateman wrote:

> Jaroslav Hajek-2 wrote:
>>
>> hi all,
>>
>> what about forking the 3-4-x branch now, and start making release
>> candidates?
>> Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
>>
>
> Shouldn't the fltk legends be included before the fork?
>
> D.

I'd also like to see the new legends included. For that I'll need to back out the outerposition code I recently added to the gnuplot backend.

Also, the colorbar isn't currently working. I'll fix that today.

Ben

Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

Jaroslav Hajek-2
On Wed, Sep 8, 2010 at 1:41 PM, Ben Abbott <[hidden email]> wrote:

> On Sep 8, 2010, at 5:18 AM, David Bateman wrote:
>
>> Jaroslav Hajek-2 wrote:
>>>
>>> hi all,
>>>
>>> what about forking the 3-4-x branch now, and start making release
>>> candidates?
>>> Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
>>>
>>
>> Shouldn't the fltk legends be included before the fork?
>>
>> D.
>
> I'd also like to see the new legends included. For that I'll need to back out the outerposition code I recently added to the gnuplot backend.
>
> Also, the colorbar isn't currently working. I'll fix that today.
>
> Ben
>
>

OK. I'm afraid I won't be able to do the release, then. If there's a
volunteer for release management, I can share a couple of useful
recipes.

--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

bpabbott
Administrator
On Sep 8, 2010, at 7:49 AM, Jaroslav Hajek wrote:

> On Wed, Sep 8, 2010 at 1:41 PM, Ben Abbott <[hidden email]> wrote:
>> On Sep 8, 2010, at 5:18 AM, David Bateman wrote:
>>
>>> Jaroslav Hajek-2 wrote:
>>>>
>>>> hi all,
>>>>
>>>> what about forking the 3-4-x branch now, and start making release
>>>> candidates?
>>>> Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
>>>>
>>>
>>> Shouldn't the fltk legends be included before the fork?
>>>
>>> D.
>>
>> I'd also like to see the new legends included. For that I'll need to back out the outerposition code I recently added to the gnuplot backend.
>>
>> Also, the colorbar isn't currently working. I'll fix that today.
>>
>> Ben
>
> OK. I'm afraid I won't be able to do the release, then. If there's a
> volunteer for release management, I can share a couple of useful
> recipes.
>
> --
> RNDr. Jaroslav Hajek, PhD
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz


It was a bit of a hassle last time, but should be branch and then do parallel commits when needed?

Ben


Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

Jaroslav Hajek-2
On Wed, Sep 8, 2010 at 2:19 PM, Ben Abbott <[hidden email]> wrote:

> On Sep 8, 2010, at 7:49 AM, Jaroslav Hajek wrote:
>
>> On Wed, Sep 8, 2010 at 1:41 PM, Ben Abbott <[hidden email]> wrote:
>>> On Sep 8, 2010, at 5:18 AM, David Bateman wrote:
>>>
>>>> Jaroslav Hajek-2 wrote:
>>>>>
>>>>> hi all,
>>>>>
>>>>> what about forking the 3-4-x branch now, and start making release
>>>>> candidates?
>>>>> Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
>>>>>
>>>>
>>>> Shouldn't the fltk legends be included before the fork?
>>>>
>>>> D.
>>>
>>> I'd also like to see the new legends included. For that I'll need to back out the outerposition code I recently added to the gnuplot backend.
>>>
>>> Also, the colorbar isn't currently working. I'll fix that today.
>>>
>>> Ben
>>
>> OK. I'm afraid I won't be able to do the release, then. If there's a
>> volunteer for release management, I can share a couple of useful
>> recipes.
>>
>> --
>> RNDr. Jaroslav Hajek, PhD
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>
>
> It was a bit of a hassle last time, but should be branch and then do parallel commits when needed?
>

Our "branches" are in fact separate repos. Essentially, after the
branch is forked, changesets can be simply pulled as long as we need
all of them (most changesets currently arriving are bug fixes). After
a diversion occurs, hg transplant needs to be used. What I used to do
is producing a sequence of candidate releases using "make dist"
eventually converging to the actual release.

If anyone wants to propose a new method, you're welcome, but be ready
to actually carry it out.

--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

Jordi Gutiérrez Hermoso
In reply to this post by bpabbott
On 8 September 2010 07:19, Ben Abbott <[hidden email]> wrote:
> It was a bit of a hassle last time, but should be branch and then do
> parallel commits when needed?

Ideally, no? Only a release manager should hold the keys to the
release repo and should be the only person in charge of pulling
bugfixes from the development repo.

Alternatively, it can be more easily done the other way around: only
bugfixes should be pushed to the release repo, assuming everyone knows
what a bugfix changeset looks like. Normal development can still
happen in the development repo, and the development repo can
periodically pull and merge with the stable repo. The release
manager's task would then be stewarding the stable repo (e.g. strip a
mistaken bugfix) and pull and merge those fixes into the development
repo.

We can also do this without making separate repos, just making a named
stable branch. Here's a couple of descriptions of how to do it:

      http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/
      http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#x_390

The Mercurial repository itself follows this release model. However, I
think you guys don't like branchy development? It's conceptually
slightly more complicated than having separate stable and development
repos and having the development repo periodically pull from the
stable repo.

If being a release manager only involves managing an hg workflow, I
can do it. If it also requires judging the quality of patches and
being intricately familiar with the codebase, then I can't.

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

Jordi Gutiérrez Hermoso
2010/9/8 Jordi Gutiérrez Hermoso <[hidden email]>:
> We can also do this without making separate repos, just making a named
> stable branch. Here's a couple of descriptions of how to do it:

And here's another one that someone produced for me after asking in IRC:

      http://bitbucket.org/brodie/named-branches-example/wiki/Home

The DAG ends up looking like this:

     http://brodierao.com/etc/namedbranches.png

Note that yellow diagonal edges bring bugfixes from stable into
default and the green diagonal edge brings all of default's changesets
into stable.

Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

John W. Eaton
Administrator
In reply to this post by David Bateman
On  8-Sep-2010, David Bateman wrote:

| Jaroslav Hajek-2 wrote:
| >
| > hi all,
| >
| > what about forking the 3-4-x branch now, and start making release
| > candidates?
| > Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
| >
|
| Shouldn't the fltk legends be included before the fork?

I was planning to make a snapshot once fltk legends were done.

I'm also willing to handle the 3.4.0 release.  I'd prefer to branch as
late as possible as I prefer to avoid having to apply/merge/transplant
changesets to two branches as much as possible.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

Thomas Weber-3
In reply to this post by Jaroslav Hajek-2
On Wed, Sep 08, 2010 at 09:18:00AM +0200, Jaroslav Hajek wrote:
> hi all,
>
> what about forking the 3-4-x branch now, and start making release candidates?
> Thomas, would you be willing to host 3.4.x on hg.tw-math.de?

Yes, sure.

        Thomas
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

David Bateman-2
In reply to this post by bpabbott
Ben Abbott wrote:

> On Sep 8, 2010, at 5:18 AM, David Bateman wrote:
>
>  
>> Jaroslav Hajek-2 wrote:
>>    
>>> hi all,
>>>
>>> what about forking the 3-4-x branch now, and start making release
>>> candidates?
>>> Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
>>>
>>>      
>> Shouldn't the fltk legends be included before the fork?
>>
>> D.
>>    
>
> I'd also like to see the new legends included. For that I'll need to back out the outerposition code I recently added to the gnuplot backend.
>
> Also, the colorbar isn't currently working. I'll fix that today.
>  
I'd say give me a couple of days (I'm not getting many octave hours into
a day lately) and I'll have the legend code done if Ben reverts his
outerposition code.

D.

Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

Jaroslav Hajek-2
In reply to this post by John W. Eaton
On Wed, Sep 8, 2010 at 6:19 PM, John W. Eaton <[hidden email]> wrote:

> On  8-Sep-2010, David Bateman wrote:
>
> | Jaroslav Hajek-2 wrote:
> | >
> | > hi all,
> | >
> | > what about forking the 3-4-x branch now, and start making release
> | > candidates?
> | > Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
> | >
> |
> | Shouldn't the fltk legends be included before the fork?
>
> I was planning to make a snapshot once fltk legends were done.
>
> I'm also willing to handle the 3.4.0 release.  I'd prefer to branch as
> late as possible as I prefer to avoid having to apply/merge/transplant
> changesets to two branches as much as possible.
>

Great, so I'm just handing back the release manager cloak to you. May
you wear it better than I did :)

--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

David Bateman-2
Jaroslav Hajek wrote:

> On Wed, Sep 8, 2010 at 6:19 PM, John W. Eaton <[hidden email]> wrote:
>  
>> On  8-Sep-2010, David Bateman wrote:
>>
>> | Jaroslav Hajek-2 wrote:
>> | >
>> | > hi all,
>> | >
>> | > what about forking the 3-4-x branch now, and start making release
>> | > candidates?
>> | > Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
>> | >
>> |
>> | Shouldn't the fltk legends be included before the fork?
>>
>> I was planning to make a snapshot once fltk legends were done.
>>
>> I'm also willing to handle the 3.4.0 release.  I'd prefer to branch as
>> late as possible as I prefer to avoid having to apply/merge/transplant
>> changesets to two branches as much as possible.
>>
>>    
>
> Great, so I'm just handing back the release manager cloak to you. May
> you wear it better than I did :)
>
>  
Nonsense, you were just fine

D.

--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

John W. Eaton
Administrator
On  8-Sep-2010, David Bateman wrote:

| Jaroslav Hajek wrote:
| > Great, so I'm just handing back the release manager cloak to you. May
| > you wear it better than I did :)
| >
| >  
| Nonsense, you were just fine

Yeah, I think you did a great job.  BTW, notice that I said I was
willing to do 3.4.0.  My history with the bug fixing releases tells me
that I won't be good at managing that process, so I would be happy if
someone else was willing to take over the job you did for the 3.0.x
and 3.2.x release series.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: release 3.4.x

bpabbott
Administrator
In reply to this post by David Bateman-2
On Sep 8, 2010, at 3:10 PM, David Bateman wrote:

> Ben Abbott wrote:
>> On Sep 8, 2010, at 5:18 AM, David Bateman wrote:
>>
>>  
>>> Jaroslav Hajek-2 wrote:
>>>    
>>>> hi all,
>>>>
>>>> what about forking the 3-4-x branch now, and start making release
>>>> candidates?
>>>> Thomas, would you be willing to host 3.4.x on hg.tw-math.de?
>>>>
>>>>      
>>> Shouldn't the fltk legends be included before the fork?
>>>
>>> D.
>>>    
>>
>> I'd also like to see the new legends included. For that I'll need to back out the outerposition code I recently added to the gnuplot backend.
>>
>> Also, the colorbar isn't currently working. I'll fix that today.
>>  
> I'd say give me a couple of days (I'm not getting many octave hours into a day lately) and I'll have the legend code done if Ben reverts his outerposition code.
>
> D.

David, I've pushed the changeset to revert the outerposition code.

Ben