[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Google Online document Plugin for KOffice
From:       Inge Wallin <inge () lysator ! liu ! se>
Date:       2010-07-05 7:53:56
Message-ID: 201007051053.56956.inge () lysator ! liu ! se
[Download RAW message or body]

On Monday, July 05, 2010 09:04:14 Boudewijn Rempt wrote:
> On Sunday 04 July 2010, Inge Wallin wrote:
> > As long as this staging area isn't the developers own harddisk and
> > reviewboard, I guess it could be done.  Right now the reviewboard seem to
> > be acting more as a blocking post than a help, given how many open
> > reviews that we have.  We have to do something about that soon.
> > 
> > 
> > For a staging area to work for me, the following two criteria have to be
> > fulfilled:
> >  * The code has to be completely visible so that other people can see it
> > and help out (as you also write above).
> >  * It must be real easy to build a koffice with the "unfinished" shapes
> > included in the build.
> 
> I'd much prefer not to split the community at all. 

Hmm, why would having some code in plugins/ and some code in plugins/staging 
split the community?  I, as a community member, could still work on all the 
code in both directories, as well as all the rest of the code.

> It's not as if the
> KOffice community is too big -- we need to be open and welcoming to
> everyone. If there is one thing I have learned from the great
> community-related presentations this year at akademy it's that dividing
> the community between "core" and "not- yet-core" developers is a sure way
> to lose the second category. Besides, who gets to decide what is
> sufficient quality? If I look back at the text-on-shape discussion, both
> versions of the patch are unfinished in some regards, for instance.

All this is true, but you have to separate the community and the code. The 
community works on all code, no matter where it is in the source tree.

> > Right now we do actually fulfill the two criteria above by having them
> > inside the normal source and disabling them at the release.  Another real
> > simple thing we could do is to create a plugins/staging/ subdirectory
> > where the plugins are developed until they are ready and then they are
> > just moved up one step.  I don't think we have enough unfinished shapes
> > being developed inside KOffice to warrant a more complex solution.
> 
> That could be a good compromise -- but I don't think even that is
> necessary.

Maybe, maybe not.  I actually think it would give us a few benefits.  And it 
would probably encourage the developers to finish the plugins to be more end 
user ready.

I myself would not have a problem moving the vectorshape to plugins/staging 
since it actually is not end user ready now (because it doesn't save). But 
there have to be clear and objective rules for when a plugin could 'move up' 
as it were.

> > And another question arises: Is it too early to do this?  Many
> > applications are not exactly polished yet either.
> 
> I think that everyone with KDE commit rights has the right to commit a new
> plugin to KOffice trunk. When it's release time, we can discuss with the
> author whether the plugin should be in the release or whether it should be
> disabled. It has worked very well for years.

Well, it could provide a form of "manhood" event.  Rites are important too.

> As far as I am concerned, Mani should commit his google docs plugin, I'm
> excited to see it and I want to play with it!

Totally agree about that!

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]