Topics

Is there consensus of when we should consider a particular badging issue as being addressed?


Kevin W. Wall
 

Just wondering what everyone's thoughts are about when a project should consider a particular issue related to the badging process to be completed. Can we / should we consider something completed only if it is in an official release or is it just sufficient to have it completed in a 'develop'  (say) branch in GitHub but still have the next planned official release several months away?

And I really don't want to hear "it is up to you". I'm interested more in if there is a consensus when you are looking at someone else's project and you see an issue that is marked as completed / implemented but it's not yet in an official release but is in a 'develop' branch. Would that cause you to perceive that project as being dishonest? Or would you prefer to see something like that to know the project is going in the right direction and making progress in terms of project maturity.

Thanks for your input.
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/.   | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.


Hanno Böck
 

On Sun, 11 Sep 2016 11:34:25 -0400
"Kevin W. Wall" <kevin.w.wall@gmail.com> wrote:

Just wondering what everyone's thoughts are about when a project
should consider a particular issue related to the badging process to
be completed. Can we / should we consider something completed only if
it is in an official release or is it just sufficient to have it
completed in a 'develop' (say) branch in GitHub but still have the
next planned official release several months away?
I'd strongly sugest that something only qualifies as resolved if it's
part of a release.

Actually I see this as a huge sign of an unhealthy project if fixes for
things linger in the code for too long and never get released. This
makes issues for downstream consumers like linux distributions very
annoying, as they have to start cherrypicking fixes from the upstream
repository or alternatively decide to pick an arbitrary state of the
repository and make that a pseudo-release. Both is more a band aid than
a good solution.

--
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


Daniel Stenberg
 

On Sun, 11 Sep 2016, Kevin W. Wall wrote:

Just wondering what everyone's thoughts are about when a project should consider a particular issue related to the badging process to be completed. Can we / should we consider something completed only if it is in an official release or is it just sufficient to have it completed in a 'develop' (say) branch in GitHub but still have the next planned official release several months away?
This also takes us back to the confusion about project vs product. We have lots of criterium about the project like way of working etc, which really isn't bound to a release at all. And then we have criteria for the specific products the project makes.

For those that describe the actual products, I think we should describe the state of already released versions or for versions that will be relased within the near future.

--

/ daniel.haxx.se


David A. Wheeler
 

Kevin W. Wall:
Just wondering what everyone's thoughts are about when a project should consider a particular issue related to the badging process to be completed. Can we / should we consider something completed only if it is in an official release or is it just sufficient to have it completed in a 'develop' (say) branch in GitHub but still have the next planned official release several months away?
And I really don't want to hear "it is up to you". I'm interested more in if there is a consensus when you are looking at someone else's project and you see an issue that is marked as completed / implemented but it's not yet in an official release but is in a 'develop' branch. Would that cause you to perceive that project as being dishonest? Or would you prefer to see something like that to know the project is going in the right direction and making progress in terms of project maturity.
I wouldn't call the project "dishonest" if they put improvements into a development branch. They're clearly taking steps to get the changes into a release.

Hanno Böck:
I'd strongly suggest that something only qualifies as resolved if it's part of a release.
Actually I see this as a huge sign of an unhealthy project if fixes for things linger in the code for too long and never get released. This makes issues for downstream consumers like linux distributions very annoying, as they have to start cherrypicking fixes from the upstream repository or alternatively decide to pick an arbitrary state of the repository and make that a pseudo-release. Both is more a band aid than a good solution.
However, I think Hanno is right, as far as *goals* are concerned. If fixes are not getting released to users, then there's a problem from the POV of the users!! We already have some criteria about getting security fixes out. However, "linger too long" can be in the eye of the beholder, especially for projects that stay in Eternal Beta (Google is one but not the only offender here). What is a "release"? What is "too long"? Those are tricky to define rigorously.

Are there particular criteria that are offenders here? I can definitely see reviewing the criteria with that in mind.


Daniel Stenberg:
This also takes us back to the confusion about project vs product. We have
lots of criterium about the project like way of working etc, which really isn't
bound to a release at all. And then we have criteria for the specific products
the project makes.
For those that describe the actual products, I think we should describe the
state of already released versions or for versions that will be relased within
the near future.
I hope they aren't *confused* - the intent was that "a project produces versions of 1+ products". Do we need to define terms? Is there a place where it's confused? But it's a fair point in the end what matters are the products/services actually released - good process, with lousy outcomes, is still a lousy outcome.

Many of the criteria focus on the *project*, because the "right" release cycle for products varies so much. There are a few rare projects where it's unlikely to have changes because it's essentially "complete" (there's a spec, it implements the spec, that's it). Stuff like "near future" is tricky :-).

Anyone have a specific criterion or two to especially focus on as an example? Or would that be missing the point?

--- David A. Wheeler


Daniel Stenberg
 

On Mon, 12 Sep 2016, Wheeler, David A wrote:

I hope they aren't *confused* - the intent was that "a project produces versions of 1+ products". Do we need to define terms? Is there a place where it's confused?
First, let me preface this by saying that this isn't terribly important, its just that we (I) keep coming back to this so I'll elaborate here for the sake of it. So let's first agree to not loose any sleep over it. Here we go.

There are some minor confusions.

I'm not sure we all agree what the differences are between a project and a product or what the definitions are, but in my view a project is roughly a set of people working together to get something done, using some sort of method or approach to get that done. One example of something a project can do, is a software product. The product is the outcome of a project's work. One or more products really.

"an individual or collaborative enterprise that is carefully planned to achieve a particular aim" is what Google define a project as, which also seems to be almost what Wikipedia says.

Very often in the FLOSS world, projects are also named as their primary product so they can often be interchanged in writing. The git project makes git. The curl project makes curl.

So as an example, the first critera under the label "FLOSS License":

"What license(s) is the project released under?"

... the *project* is not released at all. The project's *products* are released and licensed under FLOSS Licenses. The same goes for the critiera I've mentioned before (although this is less obvious):

"What is the Common Platform Enumeration (CPE) name for the project"

... and CPEs are for *products* and many projects make more than one product even if they usually have a primary one.

One could also argue that a project's web site is a separate product that the project produces. I would even guess that many projects use different licensing on the web site contents than the software they produce.

(I haven't bothered to go through to find all possible mixups, maybe these are the only two.)

So when we talk about *when* a met critiera should be fixed in a project, the only criterion that should be "in the current or a soon to be released versions" are those that are about products/software. A critera that affects the *project* has no particular reason to have to wait or to be affected by the timing of particular software releases, does it?

--

/ daniel.haxx.se