[dev] [commits] Horde branch master updated. 0d3a559c058aa995b7764d85b80df42f50324938

[Jan Schneider]

Zitat von "Michael J.Rubinsky" <mrubinsk at horde.org>:

>
> Quoting Ben Klang <ben at alkaloid.net>:
>
>> On Oct 6, 2010, at 11:11 PM, Chuck Hagenbuch wrote:
>>
>>> Quoting Eric Jon Rostetter <eric.rostetter at physics.utexas.edu>:
>>>
>>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>>
>>>>>> Yeah, but it is oh so useful...  Could we keep it as an "unofficial"
>>>>>> application or something?
>>>>>
>>>>> Sure - could be a separate github repo?
>>>>
>>>> Would it still be "unofficially supported" on the horde mailing lists
>>>> and horde web site?
>>>>
>>>> Or would you want to basically just split it off completely and not
>>>> have it mentioned on the website at all?
>>>>
>>>> Maybe an "unofficial" or "contributed" section of the web site modules
>>>> pages?
>>>>
>>>> Just not sure where you want to go with this exactly...
>>>
>>> We talked about a few options at the hackathon on this, and didn't  
>>> really get anywhere specific - we all agreed that an ecosystem of  
>>> horde apps was something to strive for, but not sure how to get  
>>> there.
>>>
>>> I won't veto (or delete it again!) if someone re-adds it, but I  
>>> still feel like we should be focusing our apps more, and that jeta  
>>> is way outside our sweet spot.
>>>
>>> -chuck
>>>
>> For what it's worth, I concur with Chuck here.  I think the easiest  
>> thing to do in the short term is to mark what the official Horde  
>> apps are.  Today I think that means everything that comes with  
>> Groupware plus probably tickets, wiki, files, photos and  
>> timetracker.  Fair candidates might also be SCM browser, news and  
>> bookmarks.
>
> I'd vote more strongly for moving News/Jonah to the official list.  
> I'd also like bookmarks moved as well, but honestly requires some  
> considerable refactoring before it could be released so I'm ok with  
> it being left in the "maybe" list.
>
>> That still leaves several apps that are very good but either not  
>> feature-complete or buggy/semi-maintained.  In this category are  
>> DNS and email managers, CDR viewer, social network, etc.   
>> Personally I rely on several of these apps daily but their  
>> existence at the same level as our flagship applications I think  
>> betrays user expectations of maturity.
>>
>> This obviously will require further discussion and actual effort,  
>> but finding some way to have a directory of Horde apps (like what  
>> Firefox does for extensions) would be a good thing for the rest of  
>> the project in my opinion.
>
> To recap my recollection of our discussions, since I don't see these  
> documented anywhere else yet:
>
> We were talking about something like a contrib channel on  
> pear.horde.org, at least for the downloading/installing of these  
> types of applications. As for where the *existing* applications  
> source should be moved to, we considered both having a single repo  
> for each application as well as keeping them where they are. The  
> argument for keeping them where they are is that anyone who would be  
> coding the apps would obviously also need the rest of the framework  
> as well, the disadvantage is that it would potentially add to  
> existing developers workload, and could be seen as "polluting" our  
> repository with non-mature apps. Other options we considered were a  
> single separate repository for these apps (rejected this idea based  
> on the lessons we learned from keeping hatchery maintained) and  
> leveraging github repositories.
>
>
> Personally, not sure what the answer is, but I'm leaning towards  
> keeping the existing non-core apps in the repo but advertise them  
> differently.

FWIW this is still my favourite. Not having them in the same repo is  
going to outdate those apps faster than you can say "refactoring". We  
should only make sure that we move only those remaining apps from CVS  
to Git that at least one developer is still interested in.

> Any new apps that would fall into this category should probably be  
> placed on github, be somehow packaged for delivering via our  
> experimental/contrib pear channel if it's deemed complete enough,  
> and be the sole responsibility of the original contributor to  
> maintain.

With the experience of other new applications that have been added  
under the premisse that the contributers are going to maintain them,  
which never happened, I agree. We need something like the incubator we  
had in CVS, so that people can prove that their code is really being  
maintained before we migth even consider adding them to the main repo.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/