Smalltalk › Frameworks & Tools › Monticello, Metacello ... › Metacello

Community configs with latest packages

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Sean P. DeNigris

Community configs with latest packages

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

Paul DeBruicker

Re: Community configs with latest packages

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.

Sean P. DeNigris

Re: Community configs with latest packages

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

Dale Henrichs

Re: Community configs with latest packages

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.
|

Paul DeBruicker

Re: Community configs with latest packages

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.

Sean P. DeNigris

Re: Community configs with latest packages

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

Dale Henrichs

Re: Community configs with latest packages

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.
|

Sean P. DeNigris

Re: Community configs with latest packages

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

Dale Henrichs

Re: Community configs with latest packages