On 13/10/2011, at 4:12 PM, Nathan Van Gheem wrote:
>> I think Alex pretty much hits the nail on the head here. In the
short
>> term, as I see it, the only sensible solution is to actively
promote
>> dual-releasing. It is really really easy, I just think awareness
is
>> not as high as it needs to be. That is probably best changed by
>> one-on-one contact with product authors (and maybe a simple FAQ
that
>> Alex (?) could write up on how to do it, so that anybody can easily
>> nag someone about this.) We can't force people to do it, but we
sure
>> as heck can make it clear what "community best practice" is.
>
> Perhaps an inbetween step is to build a better nagger?
> Something that iterates through all plone.org products and checks
pypi to
> see if there are later releases there that aren't on plone.org and
then
> emails the author each night to complain about their laziness? :)
I am a huge fan of automated shame (TM). :-) Seriously.
-1
I'm definitely against this. Just because I don't want to advertise
a product that might be for plone on plone.org doesn't mean I should
be annoyed by an automatic email system. What about all the plone.*
and plone.app.* eggs that would be classified for plone but never
should show up on plone.org? This sort of thing would probably
discourage people from releasing at all anymore IMO.
I really don't care for this whole idea. I only release things on
pypi occasionally because I don't want to the greater plone
community to ask for a lot of support for the product.
Perhaps if we made releasing to plone.org less painful this whole
issue would disappear. For instance, it is frustrating to have to
log into plone.org, go to the release and specify which version of
plone it's for and a changelog every time I make a release--kind of
reduces the effectiveness of having jarn.mkrelease automate the
process.
My suggestion was reminders ONLY for products listed in both places.
If you've never released it on plone.org then it's not going to do
anything. In anycase we have no way of know if a pypi package is plone
related or not.
On Wed, Oct 12, 2011 at 11:50 PM, Jon Stahl <[email protected]>
wrote:
On Wed, Oct 12, 2011 at 9:17 PM, Dylan Jay <[email protected]> wrote:
>> I think Alex pretty much hits the nail on the head here. In the
short
>> term, as I see it, the only sensible solution is to actively
promote
>> dual-releasing. It is really really easy, I just think awareness
is
>> not as high as it needs to be. That is probably best changed by
>> one-on-one contact with product authors (and maybe a simple FAQ
that
>> Alex (?) could write up on how to do it, so that anybody can easily
>> nag someone about this.) We can't force people to do it, but we
sure
>> as heck can make it clear what "community best practice" is.
>
> Perhaps an inbetween step is to build a better nagger?
> Something that iterates through all plone.org products and checks
pypi to
> see if there are later releases there that aren't on plone.org and
then
> emails the author each night to complain about their laziness? :)
I am a huge fan of automated shame (TM). :-) Seriously.
>>
>> In the longer term, I do think we want to seriously consider
shifting
>> Plone.org to be more of a selective Pypi scraper. We'd have to
think
>> about how to best include the ultra-important Plone version
>> compatibility metadata, but I assume that with so many smart folks
>> running around, that is solveable.
>
> I think it would be shame to not allow releases to be stored on
plone.org
> but I think we could extend PSC to allow it to automatically
mirror the
> release from pypi or at least provide links to that release.
+1. I definitely think that "scraping" includes mirroring the eggs.
:jon
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
