Community configs with latest packages

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

Community configs with latest packages

Sean P. DeNigris
Administrator
I just downloaded ConfigurationOfZincHTTPComponents from sqs/MetacelloRepository and noticed a few things:
* all packages are listed in #common, even though I'm assuming that they haven't been tested in each St that Metacello supports. Is the practice to assume #common until proven otherwise?
* each new person makes a version which updates to "latest available packages". Unless this process is backed up with tests, wouldn't it be easier to just override class>>#load to load #bleedingEdge? What does a version really mean in this context? It seems it'd be more valuable to get the latest fixes than waiting for someone (and in this case, it seems no one is accountable) to update the config. The only benefit I can see is to rollback... I try the latest stable and have a problem, so I roll back to version x.x.x that I know was working

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Community configs with latest packages

Paul DeBruicker
That's funny.  I updated the Zinc config yesterday but didn't copy it
to the MetacelloRepository.  Its in the ZincHTTPComponents

On Jun 6, 9:05 pm, "Sean P. DeNigris" <[hidden email]> wrote:
> I just downloaded ConfigurationOfZincHTTPComponents from
> sqs/MetacelloRepository and noticed a few things:
> * all packages are listed in #common, even though I'm assuming that they
> haven't been tested in each St that Metacello supports. Is the practice to
> assume #common until proven otherwise?

Zinc is only officially supported by Sven on Pharo 1.3, 1.4, and 2.0
(http://zn.stfx.eu/zn/index.html 5th paragraph).   I don't know if
anyone has tried it on Squeak, VW, VA, etc.

There were some packages in the various baselines and versions marked
as #gemstone. In the #stable: method there is a version for #gemstone
and also #common.  Which is I think a bug I created in April of 2011
and have maintained since then.  It should be #pharo and #gemstone.
I'll merge your and my version and fix that here in a bit.

> * each new person makes a version which updates to "latest available
> packages". Unless this process is backed up with tests, wouldn't it be
> easier to just override class>>#load to load #bleedingEdge? What does a
> version really mean in this context? It seems it'd be more valuable to get
> the latest fixes than waiting for someone (and in this case, it seems no one
> is accountable) to update the config. The only benefit I can see is to
> rollback... I try the latest stable and have a problem, so I roll back to
> version x.x.x that I know was working

I've been making the configs because Sven hasn't spent the time to
either learn the Metacello ropes or make them himself. I've been
working on the Gemstone port and Seaside adaptor off and on so its
been important to me to keep them up to date and have different
packages load for different platforms. With the move to git (http://
www.github.com/glassdb/zinc) for the Gemstone port I'm not sure what
we'll do.


Why override #load and make it behave differently than other configs
for just this project? Is there a way in the version of your
downstream project to load #bleedingEdge rather than #stable and have
it load what you want?

I agree that a 'version' for this project doesn't mean much in the
manner I've been making them except for rollback as you mention.

>
> Sean
>
> --
> View this message in context:http://forum.world.st/Community-configs-with-latest-packages-tp463362...
> Sent from the Metacello mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Community configs with latest packages

Sean P. DeNigris
Administrator
Paul DeBruicker wrote
That's funny.  I updated the Zinc config yesterday but didn't copy it
to the MetacelloRepository.  Its in the ZincHTTPComponents
Ha ha... my head is spinning with the multiple location thing...

Paul DeBruicker wrote
I'll merge your and my version and fix that here in a bit.
Okay, look at the Zodiac part because I fixed a typo there that was preventing Zodiac from loading. Also, I'm working on a Zodiac configuration which we can delegate to once you merge. Even though it is very simple now, I think we'll benefit from abstracting away that it's only one package for when that changes.

Paul DeBruicker wrote
I agree that a 'version' for this project doesn't mean much in the
manner I've been making them except for rollback as you mention.
On second thought, I think the versions that you're making are very valuable, so deployed applications can have a rock-solid unchanging dependency, and anyone adventurous can use #bleedingEdge. Also, because the repos have global read/write, so a buggy version might get uploaded. Maybe just add a comment to the Config saying "If you're feeling a little adventurous, you'd probably be fine loading the latest versions of all packages with #bleedingEdge"...

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Community configs with latest packages

Dale Henrichs
In reply to this post by Sean P. DeNigris


----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 9:05:17 PM
| Subject: [Metacello] Community configs with latest packages
|
| I just downloaded ConfigurationOfZincHTTPComponents from
| sqs/MetacelloRepository and noticed a few things:
| * all packages are listed in #common, even though I'm assuming that
| they
| haven't been tested in each St that Metacello supports. Is the
| practice to
| assume #common until proven otherwise?

When you start a project you might as well start out general and then specialize as needed ... this is a common problem when you have conditional code:

  You can't trust the conditional code until
  you know it has been tested

One of the reasons that I'm excited about git/github is that this kind of problem can be better managed using platform branches. If you look at the branch graph[1] for the STON project, you can easily tell (with practice?) that:

  the common/pharo/gemstone branches share a common merge point
   off the master branch branch
  there are several new commits on the Sven's master branch that have
   not been merged into my fork yet
  the amber branch is a number of commits behind the others

The separate branches don't "solve" the problem, but it does give the developer a tool that can tell him what's the status of a particular branch.

[1] https://github.com/dalehenrich/ston/network

| * each new person makes a version which updates to "latest available
| packages". Unless this process is backed up with tests, wouldn't it
| be
| easier to just override class>>#load to load #bleedingEdge?

No. The better solution is to use the #broken blessing for each of the platforms that haven't been tested and use the #stable symbolic version to indicate which is the "known-to-work" versions for each platform.

#bleedingEdge should only be used by developers of a project ... folks that are going into production with a project should never be exposed to #bleedingEdge ...

| What does
| a
| version really mean in this context? It seems it'd be more valuable
| to get
| the latest fixes than waiting for someone (and in this case, it seems
| no one
| is accountable) to update the config.

For community configurations with "obvious brokenness" it is legal to edit the configuration for a #released version and at a minimum set the blessing to #broken.... Usually these situations occur when the maintainer of a project is not bothering to maintain the configuration or the maintainer of the project doesn't care about the other "supported" platforms.

Another reason that I like git/github. For the STON project in particular Sven has stated that he isn't interested in worrying about porting STON to other platforms - a perfectly valid position. So the simple solution is for me to fork his project and maintain the ports to the other platforms myself (along with others who can fork my project and contribute updates)...github gives the developer a very nice set of tools for living in this kind of world...

| The only benefit I can see is
| to
| rollback... I try the latest stable and have a problem, so I roll
| back to
| version x.x.x that I know was working

This is where the #stable version should be declared for the platform. symbolic versions were invented to help address this kind of situation.

|
| Sean
|
| --
| View this message in context:
| http://forum.world.st/Community-configs-with-latest-packages-tp4633624.html
| Sent from the Metacello mailing list archive at Nabble.com.
|
Reply | Threaded
Open this post in threaded view
|

Re: Community configs with latest packages

Paul DeBruicker
In reply to this post by Sean P. DeNigris


On Jun 7, 8:02 am, "Sean P. DeNigris" <[hidden email]> wrote:
> Paul DeBruicker wrote
>
> > That's funny.  I updated the Zinc config yesterday but didn't copy it
> > to the MetacelloRepository.  Its in the ZincHTTPComponents
>
> Ha ha... my head is spinning with the multiple location thing...
>

Its no good.  I'm tempted to remove one of them but would not be
surprised to learn that people are actively using both.  And I think
the guidelines were to use the projects repository for exploratory
configs and then move them to MetacelloRepository when stable/
finished.  I just forget the second step too often.

> Paul DeBruicker wrote
>
> > I'll merge your and my version and fix that here in a bit.
>
> Okay, look at the Zodiac part because I fixed a typo there that was
> preventing Zodiac from loading. Also, I'm working on a Zodiac configuration
> which we can delegate to once you merge. Even though it is very simple now,
> I think we'll benefit from abstracting away that it's only one package for
> when that changes.
>

Thanks for noticing that error fixing it. I merged the changes and put
an up-to-date version of the configuration in both locations.

Reply | Threaded
Open this post in threaded view
|

Re: Community configs with latest packages

Sean P. DeNigris
Administrator
Paul DeBruicker wrote
I think
the guidelines were to use the projects repository for exploratory
configs and then move them to MetacelloRepository when stable/
finished.  I just forget the second step too often.
Yes, the current level of work required creates errors and resistance. We need tools. For now, we should add a #publish method somewhere - maybe in the toolbox - that copies the config to sqs/MetacelloRepository. The location lookup rules that Dale is working on seem promising. When they are solid, we can augment the publish function to send it out to all the expected locations.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Community configs with latest packages

Dale Henrichs
In reply to this post by Sean P. DeNigris
Sean,

Yes this multiple location thing needs to be taken care ... of course it all started because in the beginning most of the configurations were written by Mariano and myself and we often didn't have write permission for the projects that we were configuration so the MetacelloRepository was invented ... we're still in the position were a significant number of developers continue to ignore Metacello so I'm not sure that until that changes, we won't always have a problem of where to find the correct up-to-date config.

I think that a clearinghouse repository for configurations is a good idea, but the configurations ought to be vetted and tested before inclusion (the direction that pharo is going in). For mcz repositories without write rights we're still in a pickle.

For github repositories, forking is the natural answer ... then it's obvious that the config is not coming from the primary maintainer and using the network graph a developer can tell the status of the project and fork if he/she needs to make changes ....

So the rule of thumb should be that every project will have a configuration ... there may exist a variety of clearing house repositories with listings of configurations that meet the criteria of the clearing house maintainers ...

if you obtain a configuration from a clearing house, then you should be aware that you can look at the configuration and discover the "source" repository for the project and use the "source" repository when looking for the latest updates and bugfixes ...

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, June 7, 2012 8:02:54 AM
| Subject: [Metacello] Re: Community configs with latest packages
|
|
| Paul DeBruicker wrote
| >
| > That's funny.  I updated the Zinc config yesterday but didn't copy
| > it
| > to the MetacelloRepository.  Its in the ZincHTTPComponents
| >
| Ha ha... my head is spinning with the multiple location thing...
|
|
| Paul DeBruicker wrote
| >
| > I'll merge your and my version and fix that here in a bit.
| >
| Okay, look at the Zodiac part because I fixed a typo there that was
| preventing Zodiac from loading. Also, I'm working on a Zodiac
| configuration
| which we can delegate to once you merge. Even though it is very
| simple now,
| I think we'll benefit from abstracting away that it's only one
| package for
| when that changes.
|
|
| Paul DeBruicker wrote
| >
| > I agree that a 'version' for this project doesn't mean much in the
| > manner I've been making them except for rollback as you mention.
| >
|
| On second thought, I think the versions that you're making are very
| valuable, so deployed applications can have a rock-solid unchanging
| dependency, and anyone adventurous can use #bleedingEdge. Also,
| because the
| repos have global read/write, so a buggy version might get uploaded.
| Maybe
| just add a comment to the Config saying "If you're feeling a little
| adventurous, you'd probably be fine loading the latest versions of
| all
| packages with #bleedingEdge"...
|
| Sean
|
| --
| View this message in context:
| http://forum.world.st/Community-configs-with-latest-packages-tp4633624p4633730.html
| Sent from the Metacello mailing list archive at Nabble.com.
|
Reply | Threaded
Open this post in threaded view
|

Re: Community configs with latest packages

Sean P. DeNigris
Administrator
In reply to this post by Dale Henrichs
Dale Henrichs wrote
When you start a project you might as well start out general and then specialize as needed
Okay.

Dale Henrichs wrote
No. The better solution is to use the #broken blessing for each of the platforms that haven't been tested and use the #stable symbolic version to indicate which is the "known-to-work" versions for each platform.
Ah, I didn't know about that. Is it documented anywhere?

Dale Henrichs wrote
#bleedingEdge should only be used by developers of a project ... folks that are going into production with a project should never be exposed to #bleedingEdge ...
I agree.

Dale Henrichs wrote
Another reason that I like git/github.... is for me to fork his project and maintain the ports to the other platforms myself (along with others who can fork my project and contribute updates)...github gives the developer a very nice set of tools for living in this kind of world...
Yes! This is so exciting!! I think it will encourage contributions greatly. Right now, it's a PITA to contribute to projects where the repo is read-only because one has to launch an investigation into where to send code. On github, I click a button to fork and another to request a push and I'm done. Their project is not polluted, people can easily find my changes, the project owner can easily accept them if wanted, etc, etc... Plus, if a project is abandoned, my fork can more easily become the new default for people as it is linked to the old one.

Sean

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Community configs with latest packages

Dale Henrichs
The #broken blessing is documented in the Metacello tutorial:

    http://magaloma.seasidehosting.st/Metacello-Tutorial ... lesson11Blessing

and in the Metacello chapter of the PBE in the "Project Blessing and Loading" sections...

Dale

 
----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, June 7, 2012 8:32:48 AM
| Subject: [Metacello] Re: Community configs with latest packages
|
|
| Dale Henrichs wrote
| >
| > When you start a project you might as well start out general and
| > then
| > specialize as needed
| >
| Okay.
|
|
| Dale Henrichs wrote
| >
| > No. The better solution is to use the #broken blessing for each of
| > the
| > platforms that haven't been tested and use the #stable symbolic
| > version to
| > indicate which is the "known-to-work" versions for each platform.
| >
| Ah, I didn't know about that. Is it documented anywhere?
|
|
| Dale Henrichs wrote
| >
| > #bleedingEdge should only be used by developers of a project ...
| > folks
| > that are going into production with a project should never be
| > exposed to
| > #bleedingEdge ...
| >
| I agree.
|
|
| Dale Henrichs wrote
| >
| > Another reason that I like git/github.... is for me to fork his
| > project
| > and maintain the ports to the other platforms myself (along with
| > others
| > who can fork my project and contribute updates)...github gives the
| > developer a very nice set of tools for living in this kind of
| > world...
| >
| Yes! This is so exciting!! I think it will encourage contributions
| greatly.
| Right now, it's a PITA to contribute to projects where the repo is
| read-only
| because one has to launch an investigation into where to send code.
| On
| github, I click a button to fork and another to request a push and
| I'm done.
| Their project is not polluted, people can easily find my changes, the
| project owner can easily accept them if wanted, etc, etc... Plus, if
| a
| project is abandoned, my fork can more easily become the new default
| for
| people as it is linked to the old one.
|
| Sean
|
| Sean
|
| --
| View this message in context:
| http://forum.world.st/Community-configs-with-latest-packages-tp4633624p4633739.html
| Sent from the Metacello mailing list archive at Nabble.com.
|