Documentation (some pages missing)

[Sandro Martini <sa...@gmail.com>]

Hi to all, continuing here the discussion ...

> The issues you raised below are valid, but are not showstoppers, especially for an incubating project. Getting a number of successful releases out is essential for us to graduate.
>
> This is a volunteer effort, and we simply don't have the resources that a commercial project might to make sure that absolutely everything is perfect for each release. Even in commercial software development, products go out the door with known bugs and issues. That's why we have a road map - so we > can keep track of our priorities, and make sure that they are addressed at the right time.
I disagree on this, mainly for major releases, given the fact that
these are simple things to fix, and that we know already.
Shifting the release of some day shouldn't be a problem ...

> 1.3 is not the "right time" to get all of our documentation done. We need to get a stable 1.3 release out so we can promote it and raise additional awareness of the platform. Holding up the release until all the documentation is ready will prevent us from doing that, and will ultimately hinder our success.
I agree, but the good of Open Source isn't that we haven't here
commercial timelines to respect, so we can make products with high
quality ?
But maybe it's my mis-conception of Open Source ... or are we
returning to the concepts of last days, explained by Niclas ?
And form my point of view, a "good release" is the best of code, and
also the best in related material, also documentation.
And i repeat, in this case should be enough to put the same pages
already in the wiki, or are they older ?

> So I would encourage you to reconsider your vote, taking this into account.
Ok, for me it's not a problem, I don't want to have a negative effect
in the project ... I'm only trying (with my efforts, and from many
points of view) to improve the quality of this excellent project, and
this is the reason why i spend here most (and I'm thinking that could
be too much) of my (little) free time ...

What others say on this ?


Bye,
Sandro

Re: Documentation (some pages missing)

[Greg Brown <gk...@mac.com>]

>   - When bugs are discovered during normal development, they should be
>   fixed in the next release.

I think we should say that they should "generally" be fixed for the  
next release. We should always strive to have addressed all known bugs  
for any given release. But we may run into situations where certain  
low-priority (or low-impact) bugs may need to be addressed in a future  
release, due to time/resource constraints.

>   - When bugs are discovered after a release candidate has been  
> tagged,
>   they should be investigated to determine their severity.  Only  
> critical bugs
>   should hold up the release; all other bugs can go in the following  
> release.

Agreed.

>   - It's ok for a release to be missing certain features, as long as  
> those
>   features are tracked on the roadmap and prioritized according to the
>   consensus priority.  The prioritization of JIRA tickets is always  
> open for
>   debate on the dev list, though it should be kept in mind that if a  
> developer
>   chooses to work on something of lower priority, that's his or her
>   prerogative and should not be discouraged.

Agreed.

Re: Documentation (some pages missing)

[Todd Volkert <tv...@gmail.com>]

Incidentally, the bug you discovered happens to be a show-stopper, so I just
changed my vote - nice catch Sandro :)

This thread can still serve as a discussion as to future Pivot release
policy when it comes to pushing things out of a release down to a future
release.  Here's my first take, and once we all agree on this, we can check
it in as part of our project practices.

   - When bugs are discovered during normal development, they should be
   fixed in the next release.
   - When bugs are discovered after a release candidate has been tagged,
   they should be investigated to determine their severity.  Only critical bugs
   should hold up the release; all other bugs can go in the following release.
   - It's ok for a release to be missing certain features, as long as those
   features are tracked on the roadmap and prioritized according to the
   consensus priority.  The prioritization of JIRA tickets is always open for
   debate on the dev list, though it should be kept in mind that if a developer
   chooses to work on something of lower priority, that's his or her
   prerogative and should not be discouraged.

-T

On Fri, Aug 28, 2009 at 9:47 AM, Todd Volkert <tv...@gmail.com> wrote:

> Are you saying you want all documentation done for 1.3, or just the 404 not
> found pages to read "this section is not yet complete"?  If the latter,
> that's not much time at all to do.  If the former, then I'm afraid 1.3 will
> be held up for quite some time, as completing the documentation for 1.3.1 is
> going to be a very large effort.
>
> Also of consideration is the time is takes to properly deploy and test a
> release candidate.  As the release manager, each release candidate takes
> about a day of my time to get out, call for a vote, and test myself.  As
> such, I don't want to hold up a release for newly found bugs unless they
> really are show-stoppers.  The JSONViewer is a little tool - not a core part
> of the platform, so I wouldn't think that any bugs found in it should hold
> up any release.
>
> As for the broken links, I myself do not think they should hold up a
> release, but I respect your opinion.  Is your -1 vote a full veto, or just a
> vote against?
>
> -T
>
>
> On Fri, Aug 28, 2009 at 9:40 AM, Sandro Martini <sa...@gmail.com>wrote:
>
>> Hi to all, continuing here the discussion ...
>>
>> > The issues you raised below are valid, but are not showstoppers,
>> especially for an incubating project. Getting a number of successful
>> releases out is essential for us to graduate.
>> >
>> > This is a volunteer effort, and we simply don't have the resources that
>> a commercial project might to make sure that absolutely everything is
>> perfect for each release. Even in commercial software development, products
>> go out the door with known bugs and issues. That's why we have a road map -
>> so we > can keep track of our priorities, and make sure that they are
>> addressed at the right time.
>> I disagree on this, mainly for major releases, given the fact that
>> these are simple things to fix, and that we know already.
>> Shifting the release of some day shouldn't be a problem ...
>>
>> > 1.3 is not the "right time" to get all of our documentation done. We
>> need to get a stable 1.3 release out so we can promote it and raise
>> additional awareness of the platform. Holding up the release until all the
>> documentation is ready will prevent us from doing that, and will ultimately
>> hinder our success.
>> I agree, but the good of Open Source isn't that we haven't here
>> commercial timelines to respect, so we can make products with high
>> quality ?
>> But maybe it's my mis-conception of Open Source ... or are we
>> returning to the concepts of last days, explained by Niclas ?
>> And form my point of view, a "good release" is the best of code, and
>> also the best in related material, also documentation.
>> And i repeat, in this case should be enough to put the same pages
>> already in the wiki, or are they older ?
>>
>> > So I would encourage you to reconsider your vote, taking this into
>> account.
>> Ok, for me it's not a problem, I don't want to have a negative effect
>> in the project ... I'm only trying (with my efforts, and from many
>> points of view) to improve the quality of this excellent project, and
>> this is the reason why i spend here most (and I'm thinking that could
>> be too much) of my (little) free time ...
>>
>> What others say on this ?
>>
>>
>> Bye,
>> Sandro
>>
>
>

Re: Documentation (some pages missing)

[Greg Brown <gk...@mac.com>]

> I really don't understand (but could be a my limit) the needs to exit
> as soon as possible with the 1.3

There are actually some efforts underway that depend on a final 1.3  
release (specifically, some projects, presentations, and articles). We  
also need to do releases periodically to maintain visibility as well  
as to continue to streamline our understanding of the Apache process.

> i think more in general, as niclas said, as a
> team we need some more coordination / discussion of things, and as my
> opinion we should learn to work better as a team

I would suggest that you try to monitor JIRA more closely. It is our  
primary tool for tracking progress and priorities.

Re: Documentation (some pages missing)

[Todd Volkert <tv...@gmail.com>]

> release *process* issues (like the need for more documentation) are best
> brought up before we start the release process :)
>

I phrased this wrong - I meant "release *prioritization* issues"

Re: Documentation (some pages missing)

[Greg Brown <gk...@mac.com>]

> I do have
> a general belief that we should issue releases somewhat frequently  
> (we've
> been doing ~2-2.5 month intervals) to keep our users up to date with  
> the
> most recent code.

Right. I think this is very important. We need to maintain some level  
of visibility, so that developers know we're here.  :-)  We don't have  
a PR engine like Microsoft or Adobe, so we have to rely on blogs,  
articles, and word of mouth to let people know what we are doing.  
Releases help give us something to talk about.

Re: Documentation (some pages missing)

[Todd Volkert <tv...@gmail.com>]

> I really don't understand (but could be a my limit) the needs to exit
> as soon as possible with the 1.3, but if this is a priority I'll
> change my vote


There's no pressing need to get 1.3 out the door ASAP.  It's just that we
resolved all 1.3 JIRA tickets, so I started the release process.  I do have
a general belief that we should issue releases somewhat frequently (we've
been doing ~2-2.5 month intervals) to keep our users up to date with the
most recent code.


> Now, please don't take all my words here as negative (I don't find the
> right English terms here ...), really, I'm dedicating here all my very
> little time because i think this project is vary very interesting, so
> my contribution to search to give it as much as quality, from many
> points of view.


On the contrary - I appreciate your point of view.  I just wanted to make
clarify what you were suggesting.  My only constructive criticism is that
release *process* issues (like the need for more documentation) are best
brought up before we start the release process :)

Re: Documentation (some pages missing)

[Sandro Martini <sa...@gmail.com>]

Hi Todd,

> Are you saying you want all documentation done for 1.3, or just the 404 not
> found pages to read "this section is not yet complete"?  If the latter,
> that's not much time at all to do.  If the former, then I'm afraid 1.3 will
My vote was not a veto, but my intention was only to mark that in this
release candidate all isn't right, like we do in past release
candidates ...
In in this specific case, I was thinking that could be a mistake and
some pages (already in the wiki) hasn't been copied to the right
folder and so has been excluded from the zip, nothing more.

> Also of consideration is the time is takes to properly deploy and test a
> release candidate.  As the release manager, each release candidate takes
> about a day of my time to get out, call for a vote, and test myself.  As
Me too, today I've spent more than 2 hours to do all tests ...

> such, I don't want to hold up a release for newly found bugs unless they
> really are show-stoppers.  The JSONViewer is a little tool - not a core part
> of the platform, so I wouldn't think that any bugs found in it should hold
> up any release.
Ok, again my intention was to send this fixed, if the release was
blocked by the previous thing, but i agree that this is only a minor
thing.


I really don't understand (but could be a my limit) the needs to exit
as soon as possible with the 1.3, but if this is a priority I'll
change my vote ... and i think more in general, as niclas said, as a
team we need some more coordination / discussion of things, and as my
opinion we should learn to work better as a team ... the time of
anyone of us is very little, so we should try to avoid wasting time
like in this situation.


> Incidentally, the bug you discovered happens to be a show-stopper, so I just
changed my vote - nice catch Sandro :)
Oh, very good ...
And i agree absolutely also on the Release Policy idea.

Now, please don't take all my words here as negative (I don't find the
right English terms here ...), really, I'm dedicating here all my very
little time because i think this project is vary very interesting, so
my contribution to search to give it as much as quality, from many
points of view.

Note:
another of the things that I liked (and for me to join this project,
as a developer) was that Greg and Todd has always been very friendly
and available for answers, so I have the maximum respect.
And in many other projects (also Open Source) I've seen it's a rare
thing, so be happy, we could have some problem, but i think we are
making a good job.


Bye,
Sandro

Re: Documentation (some pages missing)

[Todd Volkert <tv...@gmail.com>]

Are you saying you want all documentation done for 1.3, or just the 404 not
found pages to read "this section is not yet complete"?  If the latter,
that's not much time at all to do.  If the former, then I'm afraid 1.3 will
be held up for quite some time, as completing the documentation for 1.3.1 is
going to be a very large effort.

Also of consideration is the time is takes to properly deploy and test a
release candidate.  As the release manager, each release candidate takes
about a day of my time to get out, call for a vote, and test myself.  As
such, I don't want to hold up a release for newly found bugs unless they
really are show-stoppers.  The JSONViewer is a little tool - not a core part
of the platform, so I wouldn't think that any bugs found in it should hold
up any release.

As for the broken links, I myself do not think they should hold up a
release, but I respect your opinion.  Is your -1 vote a full veto, or just a
vote against?

-T

On Fri, Aug 28, 2009 at 9:40 AM, Sandro Martini <sa...@gmail.com>wrote:

> Hi to all, continuing here the discussion ...
>
> > The issues you raised below are valid, but are not showstoppers,
> especially for an incubating project. Getting a number of successful
> releases out is essential for us to graduate.
> >
> > This is a volunteer effort, and we simply don't have the resources that a
> commercial project might to make sure that absolutely everything is perfect
> for each release. Even in commercial software development, products go out
> the door with known bugs and issues. That's why we have a road map - so we >
> can keep track of our priorities, and make sure that they are addressed at
> the right time.
> I disagree on this, mainly for major releases, given the fact that
> these are simple things to fix, and that we know already.
> Shifting the release of some day shouldn't be a problem ...
>
> > 1.3 is not the "right time" to get all of our documentation done. We need
> to get a stable 1.3 release out so we can promote it and raise additional
> awareness of the platform. Holding up the release until all the
> documentation is ready will prevent us from doing that, and will ultimately
> hinder our success.
> I agree, but the good of Open Source isn't that we haven't here
> commercial timelines to respect, so we can make products with high
> quality ?
> But maybe it's my mis-conception of Open Source ... or are we
> returning to the concepts of last days, explained by Niclas ?
> And form my point of view, a "good release" is the best of code, and
> also the best in related material, also documentation.
> And i repeat, in this case should be enough to put the same pages
> already in the wiki, or are they older ?
>
> > So I would encourage you to reconsider your vote, taking this into
> account.
> Ok, for me it's not a problem, I don't want to have a negative effect
> in the project ... I'm only trying (with my efforts, and from many
> points of view) to improve the quality of this excellent project, and
> this is the reason why i spend here most (and I'm thinking that could
> be too much) of my (little) free time ...
>
> What others say on this ?
>
>
> Bye,
> Sandro
>

Re: Documentation (some pages missing)

[Greg Brown <gk...@mac.com>]

The point is that documentation has been on the road map for 1.3.1 for  
a while (and, in fact, was a major part of our graduation discussion a  
couple of weeks ago). So, this is not a recent change, and any issues  
regarding documentation should have been raised well before now.


On Aug 28, 2009, at 9:40 AM, Sandro Martini wrote:

> Hi to all, continuing here the discussion ...
>
>> The issues you raised below are valid, but are not showstoppers,  
>> especially for an incubating project. Getting a number of  
>> successful releases out is essential for us to graduate.
>>
>> This is a volunteer effort, and we simply don't have the resources  
>> that a commercial project might to make sure that absolutely  
>> everything is perfect for each release. Even in commercial software  
>> development, products go out the door with known bugs and issues.  
>> That's why we have a road map - so we > can keep track of our  
>> priorities, and make sure that they are addressed at the right time.
> I disagree on this, mainly for major releases, given the fact that
> these are simple things to fix, and that we know already.
> Shifting the release of some day shouldn't be a problem ...
>
>> 1.3 is not the "right time" to get all of our documentation done.  
>> We need to get a stable 1.3 release out so we can promote it and  
>> raise additional awareness of the platform. Holding up the release  
>> until all the documentation is ready will prevent us from doing  
>> that, and will ultimately hinder our success.
> I agree, but the good of Open Source isn't that we haven't here
> commercial timelines to respect, so we can make products with high
> quality ?
> But maybe it's my mis-conception of Open Source ... or are we
> returning to the concepts of last days, explained by Niclas ?
> And form my point of view, a "good release" is the best of code, and
> also the best in related material, also documentation.
> And i repeat, in this case should be enough to put the same pages
> already in the wiki, or are they older ?
>
>> So I would encourage you to reconsider your vote, taking this into  
>> account.
> Ok, for me it's not a problem, I don't want to have a negative effect
> in the project ... I'm only trying (with my efforts, and from many
> points of view) to improve the quality of this excellent project, and
> this is the reason why i spend here most (and I'm thinking that could
> be too much) of my (little) free time ...
>
> What others say on this ?
>
>
> Bye,
> Sandro