Re: [OctDev] moving Octave Forge mailing list to core's mailman server

[Júlio H. <jul...@gm...>]

The mailing lists novel... KISS<http://en.wikipedia.org/wiki/KISS_principle>

us...@oc...
de...@oc...

That's enough.


2012/11/25 Juan Pablo Carbajal <aju...@gm...>

> On Mon, Nov 26, 2012 at 1:45 AM, Carnë Draug <car...@gm...>
> wrote:
> > On 26 November 2012 01:01, Daniel J Sebald <dan...@ie...>
> wrote:
> >> On 11/25/2012 04:10 PM, Carnė Draug wrote:
> >>>
> >>> On 25 November 2012 21:44, Daniel J Sebald<dan...@ie...>
>  wrote:
> >>> At the moment, the decision whether a thread belongs to the help or
> >>> octave-dev mailing list is whether the reply is "use package X from
> >>> octave forge". I'll argue that most Octave users already use at least
> >>> one of the Octave Forge packages. And I'll also argue that no one in
> >>> Octave Forge uses all the Octave Forge packages. So if the question is
> >>> how to use a function from an Octave Forge package, users on the help
> >>> mailing list already are the right people to answer it. Keeping them
> >>> separated makes no sense anymore.
> >>
> >> So there will be changes to the Octave webpage descriptions that
> >> consequently (or at least intend to) direct the bulk of OctDev to the
> >> "he...@oc..." mailing list?
> >
> > Yes. That's why this is being discussed in the maintainers mailing list.
> >
> >>>>> There's plenty of applications and packages for Octave that are not
> >>>>> part of Forge.
> >>>>
> >>>>
> >>>> That doesn't mean Octave Forge isn't primarily about packages and
> >>>> applications.
> >>>
> >>>
> >>> What is this applications you keep talking about? There's only
> packages.
> >>
> >> You are thinking of applications as in hunk of software, I suspect.  I'm
> >> speaking in terms of applied science, e.g., signal processing, civil
> >> engineering, image processing, statistics.
> >
> > Damn you homophones. Causing trouble since monkeys learned to talk.
> >
> >>>> Yes and no.  I often see discussions of bugs.  Some bugs are
> >>>> straightforward
> >>>> and remain on the tracker.  Some are either vague and difficult to
> solve
> >>>> and
> >>>> warrant help from others, hence discussion list.  Some bugs expose an
> >>>> underlying weakness in design and warrant discussion about design
> >>>> modifications.
> >>>
> >>>
> >>> That may be true in core. I do not remember that ever happening in
> >>> forge. Considering the way development is done in Forge, I wouldn't
> >>> consider this to ever be a problem.
> >>
> >>
> >> "install package" would be the conceptual development there--now stable.
> >
> > "install package" would already belong to the maintainers mailing list
> > since it's handled by pkg, itself part of core. It is, however, a very
> > good example of a maintainers discussion that developers of forge
> > should be involved.
> >
> >>> Yes it is. Not one big change though, but slowly slowly seems to be
> >>> the direction it's taking. It doesn't make sense to make that question
> >>> yet, maybe it never will. But in the mean time, when things start to
> >>> overlap, such as in the case of the mailing lists, it makes sense to
> >>> merge them. We are not discussing more than just that, mailing lists.
> >>
> >>
> >> Getting rid of an active mailing list is more than a name change.  That
> >> traffic has to go somewhere.  I doubt the package concept is going away.
> >
> > We are merging 3 mailing lists, whose subjects have been overlapping
> > too much and too often, into 2.
>
> I do agree with Carnë idea. In particular with the refinement proposed
> by jwe were everything gets merged to the current mailing lists.
>
> I do not really understand, the complication observed or proposed by
> Daniel (no ofense!). I think the issue is quite simple, so a simple
> solution should be enough.
>
> Cheers
>