[kde-community] Closing the kde-core-devel mailing list

[Kevin Krammer]

On Tuesday, 2014-08-26, 11:34:20, Aaron J. Seigo wrote:
> On Tuesday, August 12, 2014 17.31:11 Kevin Krammer wrote:
> > On Tuesday, 2014-08-12, 16:40:36, Aaron J. Seigo wrote:
> > > On Tuesday, August 5, 2014 21.28:14 Kevin Krammer wrote:

> > > review requests probably should be going elsewhere; they make following
> > > actual discussion not about specific patches more difficult.
> > 
> > I didn't mean review request as in reviewboard notifications. I meant
> > request for review of things moving into kde-review.
> 
> Ok :) So, kde-review requests ... There are two broad categories:
> 
> * module-specific
> * lone projects
> 
> An example of a module-specific category woudl be a new Calligra
> application. Does that benefit more from being announced on k-c-d, or on
> the Calligra devel ml?

I think the reason these review request go to the general list is that more 
people would like to help with reviewing them, e.g. Albert is always looking 
at i18n issues.

We can either subscribe Albert to all module lists or require that review 
requests are posted to multiple lists.
Or keep it simple for everyone and post to the shared development list.

> If kde-devel@ is the mailing list for discussing use of KDE
> frameworks/libraries (as opposed to the development of them), then this
> would be a natural place for that to occur. It would also bring some
> additional focus and energy to kde-devel@ that is quite on-topic for that
> list.
> 
> My suggestion therefore is to move kde-review announcements to kde-devel@,
> allowing k-c-d to focus on frameworks development and coordination.

That is also an option.
kde-devel is not as noisy as it used to be, so all developers could rejoin it.

> > > inter-module coordination ... should that not happen on the relevant
> > > module
> > > lists?
> > 
> > You mean multiposting to several lists, potentially ones one is not
> > subscribed to?
> 
> Ah, we have a terminology issue. When I hear "inter-module" I hear
> "something that affects 2-3 specific modules at the application level"; you
> seem to be using it as a loose synonym for "frameworks".

No, I mean the former. Application modules.

> Another example, this time yours:
> > Lets take for example my inquiry on interest for a scripting BoF.
> > I could have posted that to all module development lists, I am sure
> > posting
> > to kde-core-devel was the better choice.
> 
> Yes, k-c-d is perfect for that kind of thing; pan-KDE-software scripting is
> a frameworks issue. I don't see that as "inter-module" discussion any more
> than kcoreaddons, threadweaver, or any other frameworks level technology
> is.

Only if it involves a (potential) framework.
In this this is incidentally true.

If the scope of the BoF would just be gathering best pratices, I would have 
had to post to plasma-devel, kdepim, kwrite-devel, kwin-devel, kde-edu, kde-
games-devel, calligra-devel and those are just the ones I can think of right 
now.

I am not even subscribed to all of these, I am sure the respective list 
moderators would be thrilled to get tons of moderation requests.

> > > the reason kde-devel exists separately from kde-core-devel is to provide
> > > a
> > > place for developers working with KDE libraries and applications that
> > > doesn't also carry discussion related to work ongoing in kdelibs.
> > 
> > Sure, but asking questions about how to use frameworks will end up on the
> > frameworks list, because that's the most obvious name for people looking
> > for help on frameworks.
> 
> agreed; my suggestion is that we already have these lists: kde-core-devel
> and kde-devel. frameworks-devel ought to be closed and merged back into
> k-c-d from whence it was forked with the r-b traffic going to a new list.
> 
> > If we feel that this will be a problem we'll need "frameworks users".
> 
> we already have that: kde-devel@

Hence me writing "if".

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20140826/1308056d/attachment.sig>