[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-13 15:46:56
Message-ID: 201007131746.59073.inge () lysator ! liu ! se
[Download RAW message or body]

On Wednesday, July 07, 2010 00:13:52 Thomas Zander wrote:
> On Tuesday 6. July 2010 22.09.08 Boudewijn Rempt wrote:
> > On Tuesday 06 July 2010, Mani N C wrote:
> > > I was travelling and couldn't access my mail.
> > > Let me add my 2 cents,
> > > 
> > > I personally don't mind to put my code inside trunk or outside, if it
> > > goes with the application.
> > 
> > If it isn't in koffice/trunk, it won't be part of the release, so in that
> > sense it won't go with the application.
> 
> This is misrepresenting the concept of 'staging' area.
> While technically you are correct, it is quite important to point out that
> a choice of location is not permanent. Also the kofficeplugins repo is
> new, it might very well be released.
> In other words; it would be wrong to conclude that the only way to get
> released you need to commit in koffice/plugins.

Well...  The only way to get released *as part of KOffice* is to have it 
inside the koffice repository, e.g. in plugins/.

But you are also right that a choice of location is not permanent.  Anything 
in plugins/staging could be moved up to plugins/ if it's "ready" in some 
sense.  Just as well could anything outside the main repository be moved into 
koffice when it's ready (or before, if it goes to the staging area).

My suggestion would be that if the intention is to eventually be part of the 
KOffice release, then add the new plugin to plugins/staging/.  If it's meant 
to be an add-on, then start out in the external repository.

> > > I just have one question, Does plugin code in Kofficeplugin will remain
> > > there forever or After sometime should it be moved to trunk/plugin
> > > again ?
> > 
> > There's no process defined for that yet, so that's all a gray area.
> 
> this is misrepresenting the concept of a staging area; which is quite well
> defined by many usages inside and outside of koffice. That the KOffice
> community has not started to copy such a process and draft actual rules
> for agreement is indeed true. The rules will not be a big surprise to
> anyone that has insight in how plasma or others use this concept
> successfully already.
> In other words; it would be wrong to conclude that it will be impossible or
> even hard to move a plugin into the koffice repository if you choose to go
> for the kofficeplugins now.

What I think boud meant is that there are no written rules for KOffice yet.  
While you are right that there are many precedents for staging areas in 
general, all projects have their own rules for when a subproject is allowed 
into the main project from the staging area.  Those rules are indeed not 
defined for KOffice yet.

Regarding the last paragraph, I don't see that ever stated by Boudewijn.

> > > Only thing i'm worried about is, I don't want my work to go wasted
> > > since it is inside the source repo. I would be really happy If this
> > > will also go with the official koffice package, even from
> > > kofficeplugin.
> > 
> > Just commit it to koffice/plugins, then. There is no objection to that at
> > all.
> 
> The wording of 'no objections' is entirely correct, but your wording its
> misrepresenting the situation. There are better alternatives that were
> suggested and reasons offered for those alternatives.
> In other words; please consider the location to put the new plugin based,
> not on objections or fears, but based on the suggestions and their
> rationale.

It is not misrepresenting, it is true: there are no objections.  And as I 
suggested above, if the intention is to eventually be a part of KOffice 
proper, then by all means put the plugin into plugins/staging. This is the 
case for the code in question, or am I wrong, Mani?

> Also you and Inge were suggesting something else just earlier. A staging
> subdir. Lets not loose that again.
> 
> For Mani;
> we suggested kofficeplugins for plugins that are part of the koffice
> community, are under heavy development and will not have to deal with the
> freezes and other limiting factors.
> New plugins that need to be part of the koffice repository should go into
> plugins/staging where they can mature to a releasable state. You most
> likely need to update/compile all of koffice more often while working on
> the plugin if you choose this option. Also you have to abide by the
> freezes and release schedule.

Well...  I would argue that code that is still in staging/ would not have to 
abide by freezes.  They are not going to be released, after all.
_______________________________________________
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]