emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Modularization project (was: emacswiki GSOC)


From: Christopher Schmidt
Subject: Modularization project (was: emacswiki GSOC)
Date: Wed, 1 May 2013 14:18:34 +0100 (BST)

Xue Fuqiao <address@hidden> writes:
> On Tue, Apr 30, 2013 at 2:42 AM, Aurélien Aptel
> <address@hidden> wrote:
>
>> But you need a mentor. Since no one has contacted me for mentoring me
>> I can't submit a proposal. I've switched to a different GSoC
>> organisation/project.
>
> Me too.  I sent an email to Stefan several days ago, but there is no
> reply.  So I've switched to a different GSoC project (but under the
> same organization, GNU), sorry.

There is no entitlement to Stefan that he must do all the boring work.


I have been rambling about using package.el for the core a few
times already.

    http://article.gmane.org/gmane.emacs.help/90444

I follow lots of open source projects and participated in the SoC in
2009.  From what I can tell, only a tiny fraction of what is developed
throughout the summer by students actually makes it in the release
tarballs.  Most projects are overambitious, students do not stay with
the project after funding ends and, well, one just does not simply walk
into an open source project and revamp its inner core.  It does not work
that way.

Having that said, using package.el to rejuvenate all non-essential,
inbuilt packages sounds like a great SoC project.  There are no user
visible changes and it does not touch the C-side, either.  If this works
out, the result may build the foundation of a more accessible
distribution that works around lots of problems that have occured in the
past.[1]  This project helps users and developers alike.

What do you think of this project?

I realise this is rather late.  Is there anyone willing to work on this,
either as a mentor or as a student?  I could step in as a student.  As I
have already participated in the past, I would happily leave the honours
to someone else, though.

        Christopher

[1] What's avoided, right out of the top of my head:
- Security issues by external packages (CEDET)
- Giant, unreviewed merges a few days before the merge window closes
  (Org-Mode)
- People reporting critical bugs that have been fixed month ago
This does not include the numerous advantages of rolling releases, of
course.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]