• Link to source (Several plugins use “Documentation” link for this purpose but some also use it for actual documentation)
• Link to issues
• Link to documentation (done on some plugins)
• Version I’m looking at, release date (We have deposit date but close enough in most cases)
• Currently tagged/released version in git, tag/release date
• And if only approved items will show, Pending update in bazaar (2 is what I can see now, but 2.2 is waiting review)

On 27 Mar 2019, at 8:29 pm, Newman D.R. via Eprints-tech <eprints-tech@ecs.soton.ac.uk> wrote:

Hi all,

I think we can break down what needs to be done into several separate points:

1. Remove existing crud (old plugins that no longer work properly or plugins that were broken from the get go).

I know that there have been attempts to do this in the recent past to tidy some old plugins up.  However, this can be a difficult process and unless it is unequivocably clear a plugin should be removed, an individual Bazaar admin may not want to take that unilateral action for fear of getting into an argument with the plugin's creator.  If a number of individuals (maybe on this mailing list) want to compile lists of plugins that they think should be removed, then maybe we can reach a consensus to get rid of a least some of the crud.

2. Prevent people uploading broken plugins, which instantly become available for anyone can install.

As I think has already been mentioned, the Bazaar has accolades that can only be applied by Bazaar admins.  It does not seem unreasonable to limit the default listing you will see through a repository Available Bazaar plugins tab is limited to those items that have accolades, (if this is technically possible).  However, having unallocaded plugins available if a developer deliberately changes the Bazaar URL option for their repository would still be useful.  So if they want to do testing of the install from the Bazaar, then they can.

3. Make sure things from GitHub make it into the Bazaar

Rory has already made the suggestion of making use of Gitaar.  However, it sounds like even with assistance publishing a plugin to the Bazaar is not particularly straightforward.  Looking on the wiki to see what advice I can find shows a selection of pages under the EPrints Bazaar category [1] but I can see that the "Getting Started" page [2] has not had anything but minor changes for quite some time.  I would be willing to contribute to an effort to improve these pages.  However, this process would benefit most from incorporating the experiences of several people to make sure all bases are covered.

4. Make sure Bazaar plugins are regularly updated with changes made on GitHub

I know that there are various Bazaar plugins on the eprints GitHub [3] that are regularly updated to the Bazaar.  I agree that having corresponding GitHub releases and Bazaar plugin versions would be useful, which is not currently the case with these plugins.  However, I think there has to be some appreciation that producing the release of a plugin does require some effort on the part of the maintainer, so there is a need to be patient in waiting for "that pull request you submitted last week" to make it into the plugin as installable from the Bazaar.  I am certainly would advocate a more structured and transparent process for managing Bazaar plugin releases that could then lead to that plugin release receiving some sort of "gold standard" accolade on the Bazaar.

Regards

David Newman

[1] https://wiki.eprints.org/w/Category:EPrints_Bazaar

[2] https://wiki.eprints.org/w/Getting_Started_with_the_EPrints_Bazaar

[3] https://github.com/eprints

On 27/03/2019 08:39, Denis Pitzalis via Eprints-tech wrote:

I agree with Rory, gitaar can be a good solution, similar to how composer does in PHP. You develop your module on GitHub, then you publish it in a repository (the bazaar) when you have a stable enough version.
I take the occasion to re-propose a dependences field in the epmi so that you know that certain plugins would work with others of certain version etc etc.
Bottom line is that, as it is, the bazaar is not only useless to non devs but also it sends the wrong message to the people trying to test eprints for the first time.

Denis

Il 27 marzo 2019 09:31:27 CET, Rory McNicholl via Eprints-tech <eprints-tech@ecs.soton.ac.uk> ha scritto:

Hi all,

I think that there has grown over time a disconnect between the developers who are updating, releasing plugin code on github and the bazaar. As Yuri points out this has led to out of date versions of things persisting on the bazaar. When someone is new to the platform and tries to try out a plugin, a pretty poor impression is given.

Removing the bazaar is one (drastic) solution, but what I would propose is that it is overhauled and, most importantly, that there is an easy route for developers to publish from github to the bazaar.

Tim MB made https://github.com/eprintsug/gitaar a while back and we still use it to create epmis so that we can make our git-based packages installable with tools/epm. This little app will also build epms and (in theory) pulishe them to the bazaar, however I've tended to come a cropper when attempting this last bit (from memory, versioning goes a bit haywire and permissions are a pain).

However I think it is a very good start. I would suggest that working on gitaar *and* the bazaar so they can be used smoothly in tandem would really help with the quality of content on the bazaar. Something that would further enhance this integration would be tapping in to git releases/tags to help manage the versioning in the bazaar.

Even with this git => bazaar integration in place, the bazaar could still do with a bit of a clean out, deprecating unsupported packages and so on. I would suggest that not having public a git repo should be a barrier to inclusion in the bazaar and further to that, there should be agreed conventions concerning git releases that must be met before a plugin get's in to the bazaar.

Cheers,

Rory

Rory McNicholl

Lead developer

Digital Archives & Research Technologies

CoSector, University of London

Senate House

Malet Street

London

WC1E 7HU

t: +44 (0)20 7863 1344

e: rory.mcnicholl@london.ac.uk

w: https://cosector.com/digital-research/

The University of London is an exempt charity in England and Wales.

---

From: eprints-tech-bounces@ecs.soton.ac.uk <eprints-tech-bounces@ecs.soton.ac.uk> on behalf of Yuri via Eprints-tech <eprints-tech@ecs.soton.ac.uk>
Sent: 27 March 2019 07:40
To: eprints-tech@ecs.soton.ac.uk
Subject: Re: [EP-tech] please close the Bazaar

 

Excuse me but, for example, Recollect has the epmi in github but it is
not syncronized with the one in Bazaar. Orcid plugins and Datacite on
Bazaar are on unknown state, I cannot know if they're the latest with
less bug or more features.

If you start a new site today, will you blindly install them from Bazaar?

I suggest to certify in some way the plugins which are ok, which are
updated or current. Or have someone who does the check regularly and
upload them on bazaar. We know developers has the skill to use epmi, but
you shouldn't need to became a developer to know if a particular plugin
works or if it is ok.

If Orcid and Datacite are so important, and they are, it shouldn't be
difficult to find info about how to install and use them and be sure
you're doing the right thing.

Note: most epmi came with a local repository config, so you've also to
manage updates on config or document them clearly. Otherwise you've to
be an Eprint developer with a deep knowledge of it and not a simple
integrator.

Il 26/03/19 18:05, Will Fyson via Eprints-tech ha scritto:
> Hi All,
>
> I think there is a positive case to be made for the Bazaar - it
> remains one of the easiest ways to package and deploy content in a
> modular fashion and is used quite routinely by a number of
> repositories and developers. A number of recent developments such as
> the Generic Reporting Framework, ORCID plugins, DataCite DOI plugin
> and the REF plugins (admittedly REF is only of interest to UK
> institutions) have been quite popular - and I believe there may be
> some new plugins on the way soon such as a plugin to support Digital
> Science's Dimensions badges. Working on a Bazaar plugin is also quite
> a useful focal point for developers from different organisations and
> institutions to collaborate on a particular bit of functionality where
> there is shared interest.
>
> However I agree that there is a lot of old stuff in the repository
> that is no longer supported, out-of-date or buggy. We introduced a
> concept of accolades to try and make it clear which plugins are
> approved, supported and useful, and it should be possible to filter
> Bazaar plugins by accolades, as listed in the "Available" tab of an
> EPrints repository's admin Bazaar interface via a dropdown menu on
> EPrints 3.3.14+.  We'll look into making further changes to the
> "Available" Bazaar interface however to try and include more metadata
> (such as documentation links), and to filter out any plugins without
> an accolade by default.
>
> Many thanks,
>
> Will
>
> ------------------------------------------------------------------------
> *From:* Denis Pitzalis Via Eprints-tech <eprints-tech@ecs.soton.ac.uk>
> [eprints-tech@ecs.soton.ac.uk] *Sent:* 25 March 2019 16:37 *To:*
> Eprints-tech <eprints-tech@ecs.soton.ac.uk> *Subject:* Re: [EP-tech]
> please close the Bazaar
>
> +1
>
> On 25/03/2019 17:06, Yuri via Eprints-tech wrote:
>> Please do it.
>>
>> It is full of old and buggy plugins. In github you've all the plugin
>> updated but Bazaar shows no update on them. No button  to check if a new
>> version is available and no documentation on how to discover it. How can
>> this works?
>>
>>
>> *** Options:http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>> *** Archive:http://www.eprints.org/tech.php/
>> *** EPrints community wiki:http://wiki.eprints.org/
>> *** EPrints developers Forum:http://forum.eprints.org/
> --
> UNESCO
> <https://eur03.safelinks.protection.outlook.com/?url="">>
>
>
> *Denis Pitzalis, PhD <mailto:d.pitzalis@unesco.org>*
> Web Architect/Lead Developer
> <https://eur03.safelinks.protection.outlook.com/?url="">>
>
>
> DPI/WEB
> <https://eur03.safelinks.protection.outlook.com/?url="">>
> 7, place de Fontenoy
> 75007 Paris France
> Tel. +33 (0) 145681816
> <https://eur03.safelinks.protection.outlook.com/?url="">>
>
>
> https://eur03.safelinks.protection.outlook.com/?url="">
> <https://eur03.safelinks.protection.outlook.com/?url="">>
>
>
>
> I prefer to use encrypted email. My public key fingerprint is 45A5
> A7A5 0D01 CA58 5907 4FF8 BB51 9871 424D 0B40. Learn how to encrypt
> your email with the Email Self Defense guide.
> <https://eur03.safelinks.protection.outlook.com/?url="">>
>
>
>
> *** Options:http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive:http://www.eprints.org/tech.php/
> *** EPrints community wiki:http://wiki.eprints.org/
> *** EPrints developers Forum:http://forum.eprints.org/
>
>
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: https://eur03.safelinks.protection.outlook.com/?url="">
> *** EPrints community wiki: https://eur03.safelinks.protection.outlook.com/?url="">
> *** EPrints developers Forum: https://eur03.safelinks.protection.outlook.com/?url="">

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

Virus-free. www.avg.com

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/