Incubated modules for Phobos

[Paul D. Anderson]

I think this idea needs further consideration.

Summarizing the earlier discussion, there were four schools of 
thought:

1. This is a good idea.
2. This is a good idea, but let's use github branches.
3. This is a good idea, but let's use newsgroup postings.
4. This is a good idea, but let's use the review queue page on 
the wiki.

I'd hate to see this good idea not get implemented because we 
can't agree on the mechanism. The suggestions above are not 
mutually exclusive.

It seems to me that there are two primary requirements for this 
to be effective:

1. There should be ONE place where people can go to see what's 
under development.

2. That ONE place needs to be easy to find, as in easy for 
someone visiting the D programming language website for the very 
first time.

Here's my proposal: (Pay attention, there's a quiz at the end.)

Add another menu item under the "Community" menu to the left 
here. Call it "Under Development" or "Work in Progress" or 
"Experimental Library modules" or redefine the "Projects & 
Libraries" link. Whatever. The link would lead to a list of 
modules under development. These could be github branches, 
dsource projects, review queue items, etc. It doesn't matter how 
the project is sourced or maintained.

Anyone who has a module under development could add a URL to 
their project page at that ONE place.
  These could be in any stage of development -- just a proposal or 
maybe just a good idea, a formal specification, a beta version, a 
complete library, or even a wish list...)

There may be other, better ways to implement this, but I would 
find it very useful to have that ONE place.

For example, I spent quite a bit of time, spread over a couple of 
weeks, looking for a D language statistics library. It turns out 
there is at least one.

Quiz: 1) Where is it? 2) Why isn't it being considered for Phobos?


On Monday, 19 December 2011 at 16:46:46 UTC, Piotr Szturmaj wrote:
> Steven Schveighoffer wrote:
>> On Sun, 18 Dec 2011 10:00:35 -0500, Piotr Szturmaj
>> <bncrbme at jadamspam.pl> wrote:
>>
>>> Peter Alexander wrote:
>>>> On 18/12/11 2:18 PM, Piotr Szturmaj wrote:
>>>>> "Exp" code may be shipped with each release just like "etc" 
>>>>> code. Users
>>>>> using experimental code should be aware of breaking changes 
>>>>> that may be
>>>>> introduced with each release or even with each commit.
>>>>>
>>>>> Thoughts?
>>>>
>>>> Isn't this just reinventing git branches?
>>>>
>>>> If people have their work-in-progress branches on GitHub 
>>>> then people can
>>>> already try them out, submit pull requests etc. That's the 
>>>> whole point
>>>> of a branch.
>>>
>>> Yes, but what I propose is the centralized repository for that
>>> branches (eventual candidates to std). Currently no one knows 
>>> all
>>> modules that are being worked on.
>>
>> I think it would be enough to post something on D.announce and 
>> then
>> whoever is interested can watch your branch. Maybe even a wiki 
>> page
>> could categorize the branches.
>>
>> I agree with others that github's forking and branching 
>> mechanism works
>> quite well for developing multi-user projects. For example, 
>> both Lars
>> Kyllingstad and I are working on a new std.process module, 
>> he's doing
>> the main design and unixen implementations, I'm doing the 
>> windows
>> implementation.
>
> Okay, I agree too. The core problem is that modules after 
> inclusion become official/public instantly and API must be 
> frozen. Eventual API issues discovered after the inclusion are 
> often impossible to fix because nobody "likes" deprecations and 
> breaking changes.
>
> So, instead of making modules public from the start, I would 
> rather give some additional "beta" time for them. Interested 
> users may check out these modules in the "real world" during 
> that time. Also, beta code may introduce breaking changes 
> without worrying.
>
> I think review is a requirement of course but it is often not 
> enough. Some things may not be catched during review. Code must 
> be extensively _used_ to prove its quality.
>
> If you agree with me, there is only one additional rule to add 
> to Phobos contribution process. After a review and voting 
> process, add module to etc (or exp, whatever) for one month. 
> Then move it to std if no/little changes were made during that 
> trial. If changes are big the trial period should be extended.