Re: How are we using release branches?!

On 7/31/12 7:30 AM, Max Horn wrote:
> Hi Alexander, all,
> 
> 
> On 31.07.2012, at 15:54, Alexander Hansen wrote:
> 
>> On 7/31/12 6:38 AM, Max Horn wrote:
>>> Hi there,
>>>
>>> I am a bit confused by this commit:
>>>
>>>  Alexander Hansen master * r9a31ce1 / NEWS : Start listing features for next release. - http://git.io/HuaDZw
>>>
>>> (Before I go on: This is not a critique, but rather honest puzzlement, and I am extremely grateful to akh for the hard work he is investing into Fink!)
>>>
>>> Here is the thing: This commit on the master branch describes changes in the NEWS file for release 0.34.2. Yet we also have a release branch for the 0.34.x series: branch_0_34. This branch neither contains the NEWS file change, nor does it contain several of the changes listed in the NEWS file.
>>>
>>> So, I am somewhat unclear how development is meant to proceed from here on. Which of these is the case:
>>>
>>> 1) We simply have abandoned using release branches, 0.34.2 and future releases will be directly from master, whatever it contains.
>>>
>>> 1b) As a variation, the branch label "branch_0_34" is kept but moved over to point to the current master HEAD commit.
>>>
>>> 2) We are still using branch_0_34. Somebody will soon determine which master commits are "relevant" for 0.34.2, and those will be manually cherry picked into the release branch.
>>>
>>> 3) Something else?
>>>
>>
>> I _normally_ do the release branch simultaneously with the master for
>> bugfixes and straightforward enhancements.
> 
> 
> OK, just so I understand right what "simultaneously" mean: You commit to one branch and then cherry-pick to the other (or more or less equivalently, you simply apply the changes to both branches) ? Or do you use merging, similar to what I described?
> 
>>  Anything that's more
>> involved goes on either in my own fork or a non-release branch (cf.
>> real-10.5-EOL), to be added when we're ready for it.
> 
> OK. Again, just to make sure I understood right: Added = merged? Or "added = cherry picked" ?
> 
> 

cherry-picking.  I had thought that we didn't want just to have merge
commit messages.


>> I'm distracted right now with a boatload of crap going on so I didn't
>> sync the current changes.  I didn't expect an audit of my methodology.
> 
> Well, I just want to understand how things are to be done... In particular, I was worried that perhaps my recent commits to master should *not* have gone to master, but rather to yet another development branch. THings are a bit clearer now, but I am still puzzled... 
> 
> 
>>
>>>
>>> I am a bit puzzled by this. And if it 2), I am also a bit worried about this "un-gittish" approach. It is somewhat problematic because it would invalidate most of the testing that's been done with those commits, as they would be re-assembled in a different way to what was there before. And it is easy to forget a "relevant" commit... Anyhow, how would we decide which commits are "relevant" ?
>>>
>>>
>>
>> Right now master and branch_0_34 are identical, apart from the trivial
>> differences in the VERSION and NEWS files.
> 
> Hum? No they are not: master has the bootstrap info file changes I merged last night. It also contains several changes to perlmod/Fink files that are not on branch_0_34.
> 
> [...]
> 
>>

Sorry, right.

>> If you want us to follow some kind of specific policy, please _write it
>> down on the wiki_.
> 
> Well... does that mean the current policy is somewhere on the Wiki, then? I couldn't find anything, though... Or does it mean there is none and things just go randomly, depending on who makes the commits? In particular, I apparently already deviated from the development pattern you are following (be it implicit or explicit doesn't matter). With this, I possibly already caused extra work for you -- unintentionally of course, but still bad... :-/.
> 

Things go randomly depending on who does them.

> 
> Before I document a policy on the Wiki, there should be a policy, no? If I copy and paste what I wrote into the wiki, that doesn't help anybody, to the contrary: If it is not being followed, then this will just confuse people who read this "policy" on the Wiki that has nothing to do with reality :-).
> 
> Anyway, if you are interested in following such a scheme, I'd be happy enough to document my version of it on <http://wiki.finkproject.org/index.php/Git>, to be edited to something that helps. But if you as currently the primary committer are opposed to it / consider it more of a burden and not a help, then I don't see the point. Or perhaps you are simplHence I am asking here first... :-). 
> 
> 
> Thanks for the explanations so far,
> Max
> 


-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core