Hello,
On 10/13/11 1:12 AM, 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
<http://plone.org/> products and checks pypi to
> see if there are later releases there that aren't on plone.org
<http://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 <http://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 <http://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 <http://plone.org> less
painful this whole issue would disappear. For instance, it is
frustrating to have to log into plone.org <http://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.
+1. This comes up from time to time. Certainly a PyPI-compatible PSC has
gone a long way toward making releasing packages to plone.org trivial.
But we need to take the next step and customize the process a bit to fit
plone.org e.g. by making it possible to define
Plone-version-compatibility in setup.py.
I've not had time to look into this, but PSC is in the
github.com/collective now in case anyone wants to poke at it (we either
need to do it The Right Way™, if possible, using existing setuptools
metadata API methods, or come up with a hack-around to make it work).
And re: the issue in general, there are two approaches:
- "outsource" as much as you can to the greater Python ecosystem i.e. PyPI.
- "encapsulate" as much as you can in the Plone dog-bowl to show off our
skills.
The former is what we should be doing when we're overwhelmed with
maintaining our infrastructure (as we kind of are now IMO). The latter
we should do when we are on top of everything and can afford to take the
next bold step.
2cents,
Alex
On Wed, Oct 12, 2011 at 11:50 PM, Jon Stahl <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Oct 12, 2011 at 9:17 PM, Dylan Jay
<[email protected]
<mailto:[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 <http://plone.org>
products and checks pypi to
> see if there are later releases there that aren't on plone.org
<http://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 <http://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]
<mailto:[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
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
