[dev] Horde 5?

[Michael J Rubinsky]

Quoting Vilius ?umskas <vilius at lnk.lt>:

> Sveiki,
>
> Tuesday, February 28, 2012, 4:54:33 PM, you wrote:
>
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>>> So I can wait for git reorganization, under the condition that we
>>> need to fix branch naming/organization.  Horde 5 needs to be split
>>> to a topic branch immediately before releasing the initial version,
>>> and we need to use master for bleeding-edge development going forward.
>
>> I'm confused as to why it matters what we call the branch we do
>> bleeding-edge development in? "master" is just a name, as is "develop"
>> for that matter. There is nothing magical about the "master" branch.
>> What am I missing?
>
> I  think  Michael  M means that master by default points to HEAD.
> You  can  change  master  to  point to whatever you want though.

That's exactly my point though, there is nothing that says that  
"master" has to be special in anyway.


> Not  as  my  vote  counts here,  but I think Michael's suggestion to branch
> stable  release  is  logical. At least it has a proven track record in
> Fedora   development.  What  Fedora  does  is  they  do development in
> "master"  development unstable branch (or  "develop",  or  whatever you
> wanna call it). After planning and major development ends they branch
> out   "next_stable_release"   from   "master".  Then  they  do all the
> alpha,     beta     and     RC     releases   in "next_stable_release"
> branch.  After  the  release,  all the bugfixes and minor features are
> applied  back to "next_stable_release" from "master". This way you end
> up  with  branches  for  every  major  release,  but that is not a big
> problem.  You  can  actually delete old unsupported branches if needed
> and still have all the log from master branch.

The original issue that Michael is trying to solve (if I am  
understanding correctly) is conflicts caused by merging changes from  
one branch to another...and possibly having to merge those branches  
back again. Regardless of what we call the branches, the same problem  
will still exist. Bug fixes in whatever branch we commit them to will  
still need to be merged back to the current development branch.


> Again, I know that my vote doesn't count here,

Opinions/viewpoints are always valuable :)

> but personally me would
> be  against spliting repository for every application or/and framework
> library.  Usually  I  do  only  minor bug fixes, it would be a pain to
> keep  50 or more repositories up to date in development environment,
> because all Horde components are interconnected and you cannot develop
> and test if one of them is outdated.

While I, too, am somewhat opposed to splitting the repo, I have to  
disagree with some of your reasoning. We are striving to make our  
components atomic. In fact, most of our framework libraries ARE  
actually usable as stand-alone components, and do not require a  
traditional horde install to work. That is one of the arguments for  
splitting the framework libraries - to make them appear more atomic  
and to relieve a developer from the chore of having to install the  
whole horde stack if he/she wants to help develop the code for a  
single library.


-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org