OF: proposal for reviewing packages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

OF: proposal for reviewing packages

Colin Macdonald-2
I've been somewhat following the various threads.  Here is a small
suggestion to help with workload of the "team of admins" being discussed:

Currently we package maintainers upload a tarball (and a doc tarball).
We then wait for "team of admins" (nee Carnë) to process.

Instead, we could first require that *another* package maintainer needs
to "sign-off".  This person would ensure the package installs, tests
pass on their machine, code is up-to-date on sourceforge, maintainers
Makefile functions correctly, or whatever else seems appropriate (e.g.,
a checklist on the wiki).

For example:

   1. I submit a ticket for a new Symbolic release.
   2. Oliver (say) reviews that ticket and gives it a "+1".
   3. "team of admins" can release it.

Oliver is motivated to do this review because when he wants to release
Interval, others (esp. me) will be motivated to review it.  Thus an
additional benefit is that we newcomer OF maintainers become more
familiar/involved with each others' packages, thus improving the OF
community.

best,
Colin

Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

Oliver Heimlich
On 12.01.2017 21:26, Colin Macdonald wrote:

> I've been somewhat following the various threads.  Here is a small
> suggestion to help with workload of the "team of admins" being discussed:
>
> Currently we package maintainers upload a tarball (and a doc tarball).
> We then wait for "team of admins" (nee Carnë) to process.
>
> Instead, we could first require that *another* package maintainer needs
> to "sign-off".  This person would ensure the package installs, tests
> pass on their machine, code is up-to-date on sourceforge, maintainers
> Makefile functions correctly, or whatever else seems appropriate (e.g.,
> a checklist on the wiki).
>
> For example:
>
>   1. I submit a ticket for a new Symbolic release.
>   2. Oliver (say) reviews that ticket and gives it a "+1".
>   3. "team of admins" can release it.
>
> Oliver is motivated to do this review because when he wants to release
> Interval, others (esp. me) will be motivated to review it.  Thus an
> additional benefit is that we newcomer OF maintainers become more
> familiar/involved with each others' packages, thus improving the OF
> community.
>
> best,
> Colin
>


I give +1 to this proposal.

All we have to do is subscribe to the feed [1] to be informed of new
releases and maybe write a short message that we started a peer review
for the release (to reduce the risk that several people do redundant work).

Oliver

[1] https://sourceforge.net/p/octave/package-releases/feed.rss

Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

Colin Macdonald-2
On 12/01/17 13:30, Oliver Heimlich wrote:
> All we have to do is subscribe to the feed [1] to be informed of new
 >
> [1] https://sourceforge.net/p/octave/package-releases/feed.rss

I went to start a wiki page with a review checklist but there is already
a pretty good list under "Forge release manager" at [2].  I tried to add
your rss link but I forget the wiki password :-/

[2] http://wiki.octave.org/Octave-Forge

Colin

Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

Juan Pablo Carbajal-2
On Thu, Jan 12, 2017 at 11:44 PM, Colin Macdonald <[hidden email]> wrote:

> On 12/01/17 13:30, Oliver Heimlich wrote:
>>
>> All we have to do is subscribe to the feed [1] to be informed of new
>
>>
>>
>> [1] https://sourceforge.net/p/octave/package-releases/feed.rss
>
>
> I went to start a wiki page with a review checklist but there is already a
> pretty good list under "Forge release manager" at [2].  I tried to add your
> rss link but I forget the wiki password :-/
>
> [2] http://wiki.octave.org/Octave-Forge
>
> Colin
>

Seems like a reasonable workflow +1.
However we need to close other issues first.

Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

Olaf Till-2
In reply to this post by Oliver Heimlich
On Thu, Jan 12, 2017 at 10:30:12PM +0100, Oliver Heimlich wrote:

> On 12.01.2017 21:26, Colin Macdonald wrote:
> > I've been somewhat following the various threads.  Here is a small
> > suggestion to help with workload of the "team of admins" being discussed:
> >
> > Currently we package maintainers upload a tarball (and a doc tarball).
> > We then wait for "team of admins" (nee Carnë) to process.
> >
> > Instead, we could first require that *another* package maintainer needs
> > to "sign-off".  This person would ensure the package installs, tests
> > pass on their machine, code is up-to-date on sourceforge, maintainers
> > Makefile functions correctly, or whatever else seems appropriate (e.g.,
> > a checklist on the wiki).
> >
> > For example:
> >
> >   1. I submit a ticket for a new Symbolic release.
> >   2. Oliver (say) reviews that ticket and gives it a "+1".
> >   3. "team of admins" can release it.
> >
> > Oliver is motivated to do this review because when he wants to release
> > Interval, others (esp. me) will be motivated to review it.  Thus an
> > additional benefit is that we newcomer OF maintainers become more
> > familiar/involved with each others' packages, thus improving the OF
> > community.
> >
> > best,
> > Colin
> >
>
>
> I give +1 to this proposal.
>
> All we have to do is subscribe to the feed [1] to be informed of new
> releases and maybe write a short message that we started a peer review
> for the release (to reduce the risk that several people do redundant work).
For external packages, no objections. For controled packages, a person
with project oversight should check the release.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

Carnë Draug
In reply to this post by Colin Macdonald-2
On 12 January 2017 at 20:26, Colin Macdonald <[hidden email]> wrote:

> I've been somewhat following the various threads.  Here is a small
> suggestion to help with workload of the "team of admins" being discussed:
>
> Currently we package maintainers upload a tarball (and a doc tarball). We
> then wait for "team of admins" (nee Carnë) to process.
>
> Instead, we could first require that *another* package maintainer needs to
> "sign-off".  This person would ensure the package installs, tests pass on
> their machine, code is up-to-date on sourceforge, maintainers Makefile
> functions correctly, or whatever else seems appropriate (e.g., a checklist
> on the wiki).
>
> For example:
>
>   1. I submit a ticket for a new Symbolic release.
>   2. Oliver (say) reviews that ticket and gives it a "+1".
>   3. "team of admins" can release it.
>
> Oliver is motivated to do this review because when he wants to release
> Interval, others (esp. me) will be motivated to review it.  Thus an
> additional benefit is that we newcomer OF maintainers become more
> familiar/involved with each others' packages, thus improving the OF
> community.
>

This has always been the case, the releases are open for anyone to
review.  It just happens that very few developers actually do it
(Marco Atzeri is probably the person who does it more often).  I am
not sure if you need to do anything to get notifications from
sourceforge about pending releases.  I don't remember having to do
anything to get the notifications.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

PhilipNienhuis
Carnë Draug wrote
On 12 January 2017 at 20:26, Colin Macdonald <[hidden email]> wrote:
> I've been somewhat following the various threads.  Here is a small
> suggestion to help with workload of the "team of admins" being discussed:
>
> Currently we package maintainers upload a tarball (and a doc tarball). We
> then wait for "team of admins" (nee Carnë) to process.
>
> Instead, we could first require that *another* package maintainer needs to
> "sign-off".  This person would ensure the package installs, tests pass on
> their machine, code is up-to-date on sourceforge, maintainers Makefile
> functions correctly, or whatever else seems appropriate (e.g., a checklist
> on the wiki).
>
> For example:
>
>   1. I submit a ticket for a new Symbolic release.
>   2. Oliver (say) reviews that ticket and gives it a "+1".
>   3. "team of admins" can release it.
>
> Oliver is motivated to do this review because when he wants to release
> Interval, others (esp. me) will be motivated to review it.  Thus an
> additional benefit is that we newcomer OF maintainers become more
> familiar/involved with each others' packages, thus improving the OF
> community.
>

This has always been the case, the releases are open for anyone to
review.  It just happens that very few developers actually do it
(Marco Atzeri is probably the person who does it more often).  I am
not sure if you need to do anything to get notifications from
sourceforge about pending releases.  I don't remember having to do
anything to get the notifications.
FWIW, I only ever got notifications for the tickets I uploaded there myself.
So some form of subscription might be required.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

marco atzeri-2


On 29/01/2017 21:28, PhilipNienhuis wrote:

> Carnë Draug wrote
>> On 12 January 2017 at 20:26, Colin Macdonald &lt;
>
>> cbm@.ubc
>
>> &gt; wrote:
>>> I've been somewhat following the various threads.  Here is a small
>>> suggestion to help with workload of the "team of admins" being discussed:
>>>
>>> Currently we package maintainers upload a tarball (and a doc tarball). We
>>> then wait for "team of admins" (nee Carnë) to process.
>>>
>>> Instead, we could first require that *another* package maintainer needs
>>> to
>>> "sign-off".  This person would ensure the package installs, tests pass on
>>> their machine, code is up-to-date on sourceforge, maintainers Makefile
>>> functions correctly, or whatever else seems appropriate (e.g., a
>>> checklist
>>> on the wiki).
>>>
>>> For example:
>>>
>>>   1. I submit a ticket for a new Symbolic release.
>>>   2. Oliver (say) reviews that ticket and gives it a "+1".
>>>   3. "team of admins" can release it.
>>>
>>> Oliver is motivated to do this review because when he wants to release
>>> Interval, others (esp. me) will be motivated to review it.  Thus an
>>> additional benefit is that we newcomer OF maintainers become more
>>> familiar/involved with each others' packages, thus improving the OF
>>> community.
>>>
>>
>> This has always been the case, the releases are open for anyone to
>> review.  It just happens that very few developers actually do it
>> (Marco Atzeri is probably the person who does it more often).  I am
>> not sure if you need to do anything to get notifications from
>> sourceforge about pending releases.  I don't remember having to do
>> anything to get the notifications.
>
> FWIW, I only ever got notifications for the tickets I uploaded there myself.
> So some form of subscription might be required.
>
> Philip
>

the page
https://sourceforge.net/p/octave/package-releases/?source=navbar#

allows subscription, see mail icon.
Validation before release is useful to test packages on platform
that the maintainer can not check, like cygwin for me.


Regards
Marco





c.
Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

c.
In reply to this post by Carnë Draug

On 29 Jan 2017, at 17:58, Carnë Draug <[hidden email]> wrote:

> (Marco Atzeri is probably the person who does it more often).
The debian packagers also do review pacakge releases and provide feedback, but only after the release is done.

c.



Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

jbect
In reply to this post by marco atzeri-2
Le 29/01/2017 à 22:13, Marco Atzeri a écrit :
FWIW, I only ever got notifications for the tickets I uploaded there myself.
So some form of subscription might be required.

Philip


the page
https://sourceforge.net/p/octave/package-releases/?source=navbar#

allows subscription, see mail icon.
Validation before release is useful to test packages on platform
that the maintainer can not check, like cygwin for me.


Apparently the default behaviour is like this:

 * admins are automatically subscribed to the email alerts of the package release tracker, which would explain why Carnë didn't remember doing anything special for it.

 * other users ("Developer", "Member" or "authenticated" group) receive alerts for the tickets that they have created, or when they have contributed to the discussion.


Anyway, for those who want to be informed of the activity on the package release tracker, there are two solutions:

 * subscribe to the RSS feed, as suggested earlier by Oliver,

 * or subscribe to the email alerts, as suggested by Marco.

Both options are available on the tracker page [1] through small icons located in the top "package release" bar, next to the "Maximize" button.


All those who want to participate to the review of packages should subscribe now to one of the two types of alerts.

We don't have yet a shared "check list", but we will work on it.  You can already start to contribute by doing the following steps when someone requests a package release:

a) download the package tarball from the ticket (or try to reproduce it from the source repo using "make dist"),

b) check the md5sum,

c) install the package,

d) run the unit tests,

e) report errors, warnings or comments on the tracker  (along with any relevant piece of information: platform, version of Octave, version of dependencies, etc.).


@++
Julien


[1] https://sourceforge.net/p/octave/package-releases/

PS : there is the possibility to activate a voting system on the package tracker.  It is not currently activated, but we can activate it if enough people think it's a good idea.

Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

NJank


On Jan 31, 2017 7:14 AM, "Julien Bect" <[hidden email]> wrote:
Le 29/01/2017 à 22:13, Marco Atzeri a écrit :

d) run the unit tests,

e) report errors, warnings or comments on the tracker  (along with any relevant piece of information: platform, version of Octave, version of dependencies, etc.).

Neophyte question: is there a way to just run tests associated with a package, or after installation would you just run __run_test_suite__ for the full installation?
c.
Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

c.

On 31 Jan 2017, at 14:11, Nicholas Jankowski <[hidden email]> wrote:

>
>
> On Jan 31, 2017 7:14 AM, "Julien Bect" <[hidden email]> wrote:
> Le 29/01/2017 à 22:13, Marco Atzeri a écrit :
>
> d) run the unit tests,
>
> e) report errors, warnings or comments on the tracker  (along with any relevant piece of information: platform, version of Octave, version of dependencies, etc.).
>
> Neophyte question: is there a way to just run tests associated with a package,
No, there isn't.

> or after installation would you just run __run_test_suite__ for the full installation?
No, that won't work for packages that contain compiled functions.

There is a project being proposed for GSoC about improving pkg.m, I do think that this would be one important feature to add.

c.




Reply | Threaded
Open this post in threaded view
|

Re: OF: proposal for reviewing packages

jbect
Le 31/01/2017 à 14:28, c. a écrit :

> On 31 Jan 2017, at 14:11, Nicholas Jankowski <[hidden email]> wrote:
>
>> On Jan 31, 2017 7:14 AM, "Julien Bect" <[hidden email]> wrote:
>> Le 29/01/2017 à 22:13, Marco Atzeri a écrit :
>>
>> d) run the unit tests,
>>
>> e) report errors, warnings or comments on the tracker  (along with any relevant piece of information: platform, version of Octave, version of dependencies, etc.).
>>
>> Neophyte question: is there a way to just run tests associated with a package,
> No, there isn't.

Yes, you *can* use __run_test_suite__ to run the tests of a specific
package.  For instance:

pkg load stk
__run_test_suite__ ({'/home/bect/octave/stk-2.3.4'}, {})

runs all the test for stk 2.3.4 (assuming that it is installed in
/home/bect/octave/stk-2.3.4, of course).


>> or after installation would you just run __run_test_suite__ for the full installation?
> No, that won't work for packages that contain compiled functions.

It is true that the above solution *might* not work for packages that
contain compiled functions.

In the above example (stk), the tests associated to mex-files are
actually located in associated m-files, so they are run by
__stk_run_test_suite__.

In the case of oct-files with unit test located inside the source files,
indeed they are not run.

> There is a project being proposed for GSoC about improving pkg.m, I do think that this would be one important feature to add.

You should look at the following bug reports first:

https://savannah.gnu.org/bugs/?41298
https://savannah.gnu.org/bugs/?41215

The patch proposed by Lachlan for #41298 modifies "pkg install" and test
to extract/run the tests located in oct-files.

The patch proposed by Oliver for #41215 makes it easier to run all the
tests using a new "pkg test" command.

These patches have been waiting for more than one year for someone to
review them ;-)

@++
Julien