[dev] Horde 5?

[Vilius Šumskas]

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.

-- 
Best regards,
 Vilius