User Tools

Site Tools


PLD ToDo List

There are at least two “streams” of development for PLD – first one consists mostly of the day to day updates of various packages and making sure they reach our FTP servers (and those updates generate the bulk of discussions on our mailing lists).

The second “stream” however is made of decisions that have the potential to affect the way PLD is developed in a broader sense. It might be about some organizational changes, like issuing new policies or doing larger changes to the development infrastructure or parts of the core distribution, that have more widespread consequences.

The point of this page is to list the second type of proposals – the ones that have the potential to fix (or break for that matter) more things than just a few packages.

Rules of editing

The most fundamental rule of editing this page – just because you came up with an idea doesn't mean you need to write it here. Before actually taking the time to write down whatever is that you've came up with, do make the effort of talking about it with a couple of people and having at least the major parts of your proposal figured out. Filling this page with a bunch of loose sentences without much thought behind them will be frowned upon.

And a technical note – should a proposal start to grow, let's say beyond two or three paragraphs, it's a really good idea to create a separate page for it with the name of that page starting with TODO/ (for example: TODO/InsaneDevelopersDetentionProgram).


Writing ideas down for the sake of writing them down doesn't make much sense, now does it. What follows is an explanation of how exactly this page is supposed to fit in the Grand Scheme of Introducing New Ideas Into PLD.

The most important thing to keep in mind regarding this page – just because something is present here doesn't mean it's (a) actually doable and (b) there is a consensus that it's the right thing to do.

The idea of this page is to gather precise information on everything regarding the implementation of a given idea. One should start out with a few paragraphs regarding the major issues and with time fill in all the missing details, comments on various controversies, links to public discussions regarding the issue (especially should a given discussion greenlight the idea for implementation), etc, etc.

Ideally one should start with some basic (but sound) ideas, then reinforce them with implementation details, once everything's in place, send a link to the appropriate mailing list, deal with any issues raised there (updating the pages accordingly) and, if there's a consensus that the idea should be implemented, update with a link to that specific discussion.

Now, this might sound like a waste of time, since it results in producing a lot of text for no apparent reason. There is however one thing that's worth keeping in mind – developing an idea, as in discussing it, thinking about it and doing some initial tests is the fun part. Doing the actual implementation is the boring and time consuming part.

There's no guarantee that the person responsible for the initial idea will actually have enough time on her hand to carry out the implementation, so the only way not to loose all the energy put into developing the idea itself is to write it down in a verbose manner, so that someone else will be able to understand what's it all about and either help with it or do it herself alltogether.

Hence this page.


Builder Infrastructure

FTP Infrastructure

todo.txt · Last modified: 2008-08-02 23:39 by grizz