[dev] Horde 5?

Gunnar Wrobel wrobel at horde.org
Tue Feb 28 19:20:52 UTC 2012 

Zitat von Vilius ?umskas <vilius at lnk.lt>:

> Sveiki,
>
> Tuesday, February 28, 2012, 7:37:42 PM, you wrote:
>
>
>> 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.
>
> I'm not git export but logically  I  think  there are three cases:
>
> 1) bug fixes should be done on most up to date
> development   branch   and   only  then  backported to stable by using
> cherry-picking, not the merge.
>
> 2) if a bugfix becomes a major feature or a BC breaking change,
> then it should not be backported to stable at all.
>
> 3)  minor  features  that  from the start are aimed to go into stable,
> should   be  started on stable and later merged to development branch.
> Or  better  yet,  start it on topic branch and merge it to both stable
> and dev branges.
>
>>> 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.
>
> Yes,  most of the libraries doesn't require a whole horde install, but
> still  they  need  other libraries usually. At least Horde_Autoloader,
> Horde_Exception,  Horde_Translation  and a few others. I don't see how
> splitting  the  repository  would help here. Quite the opposite. Let's
> say I want to work on Horde_View. For splitted repository I would have
> to  actually know the dependency list and grab repositories one by one
> for 5-7 libraries.
>
> Or  let's say I would want to work on a new Horde application.  
> Again, I would have
> to  actually  know  all  the  features  I  want  to  implement  in new
> application  in  advance,  clone  all needed libraries one by one, and
> update them later during development.
>
> At  least  for  me  cloning one repository is a lot easier. Especially
> when  git  is so great with big repositories and considering speed of
> the internet nowaways.

This is a question of having the right tools for the job. Given the  
toolset we currently use you are of course right. That wouldn't make  
any sense and is way to cumbersome.

But other PHP frameworks are doing exactly the same thing: they start  
to split their software into components. This makes reuse a lot  
easier. Developers can choose the best parts from the frameworks they  
like. And having clearly delineated interfaces between your modules  
help the development in general.

One of the results from Symfony 2 is the "composer" tool: It is  
specifically designed for this "many-git-repositories" situation. They  
try to use it as package manager in general and I'm still skeptical if  
that will really work out. But for the development situation it may  
actually help.

We have our own "components" tool which is also targeting the  
component based development and release management. I would also add  
stuff we are missing there.

So all in all I would say we can split if there is no impediment of  
the development process.

Which - btw - is an unlikely result if we'd try to squeeze it in  
before Horde 5.0. So while I'd like to split I'm definitely in favor  
of doing that during a somewhat more quiet period.

Cheers,

Gunnar

>
> --
> Best regards,
>  Vilius
>
> --
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de

More information about the dev mailing list