Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » Releasing U++ » Bazaar....
Bazaar.... [message #15164] Sun, 06 April 2008 08:22 Go to next message
mirek is currently offline  mirek
Messages: 12096
Registered: November 2005
Ultimate Member
Well, I was long thinking about the best method of including "fruits of Bazaar".

I do not like current mode, when it is included as separate nest not linked in any package.

I rather propose this:

Let us choose packages polished enough (vote!). Let us put them into uppsrc for distribution purposes and also examples and reference examples of such packages to normal examples or reference.

However, let us write (or, better, let package authors) to mark such packages as "Bazaar: packagename by author", like

"Bazaar: DockCtrl by James Thomas"

Of course, later in the process, when vindicated, I would like to move such packages into uppsrc proper, giving their autors access to the repository.... (I am 85% convinced we will finally move to svn after this realease too).

Mirek
Re: Bazaar.... [message #15169 is a reply to message #15164] Sun, 06 April 2008 21:45 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior Contributor
luzr wrote on Sun, 06 April 2008 08:22

Well, I was long thinking about the best method of including "fruits of Bazaar".

I do not like current mode, when it is included as separate nest not linked in any package.



Well, I'm using it adding Bazaar nest to my project's assembly (or to myapps) and it works quite well. For testing purposes, it's just enough to add a Bazaar assembly with just Bazaar and uppsrc, and you can compile demos.

IMHO whould be not a bad idea to add a Bazaar assembly (with just bazaar and uppsrc) for testing, add Bazaar nest to myapps AND leave there all still unpolished stuffs, while polished ones could be in uppsrc directly. It makes no harm to have an assembly with testing stuffs, it allows us to play with new packages even if they're still buggy.

Max
Re: Bazaar.... [message #15196 is a reply to message #15164] Tue, 08 April 2008 16:51 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 801
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor

I think the new assembly "bazaar" should be included, so anyone can check the current upp/bazaar directory right after installing new upp version in the "Select main package" dialog.

There's further question how to link it into MyApps? To use any bazaar package you have to add bazaar directory into MyApps's nests? Maybe this can be pre-set right from installation, if there's no conflict between bazaar package and uppsrc package.

But in case we will start to move packages from bazaar to uppsrc such conflicts may arise in the future, so before we add bazaar nest automagically to MyApps some upp-guru should tell exactly what/how/when can be broken when tho packages collide and how TheIDE will behave in such case.

(that means I fully support the Max's post, I'm just not sure about setting the bazaar nest into MyApps after installation, is it safe?)

Edit:
If adding bazaar nest is safe, maybe there's no need to move packages from bazaar at all (unless they are natural fit for core package, like DockControl seems to me). That way it will be easy to recognize which packages are optional "3rd party" things, and which are core packages supported directly by Mirek and Unodgs.

[Updated on: Tue, 08 April 2008 16:58]

Report message to a moderator

Re: Bazaar.... [message #15199 is a reply to message #15196] Tue, 08 April 2008 21:15 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 916
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Mostly agreed with mr_ped. Only one addition: all bazaar packages must be subjects for voting. For example, after 2-3 months of successful usage within bazaar, and if enough people vote for this package in corresponding topic, package is moved from Bazaar to Core.
Re: Bazaar.... [message #15200 is a reply to message #15164] Tue, 08 April 2008 21:51 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 801
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor

Keep in mind there's serious question about maintenance.
So just because people love to USE some package, that love will not do a maintenance upon it for every new upp version.

I think things like DockingControl have to be adopted by Mirek anyway somewhere in the future, so even if the original author will disappear, somebody else will have to maintain it.

But I would be cautious about moving things from Bazaar to Core.
I think the Bazaar nest alone is excellent way to let U++ users know: "this" package is not fully supported by Core developers, so everyone can evaluate the risk of using it.

Once enough of core developers get used to some Bazaar package source, so they can do at least some basic maintenance, then it's IMHO better time to move it.
Re: Bazaar.... [message #15212 is a reply to message #15169] Thu, 10 April 2008 02:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12096
Registered: November 2005
Ultimate Member
mdelfede wrote on Sun, 06 April 2008 15:45

luzr wrote on Sun, 06 April 2008 08:22

Well, I was long thinking about the best method of including "fruits of Bazaar".

I do not like current mode, when it is included as separate nest not linked in any package.



Well, I'm using it adding Bazaar nest to my project's assembly (or to myapps) and it works quite well. For testing purposes, it's just enough to add a Bazaar assembly with just Bazaar and uppsrc, and you can compile demos.



I guess this is ok for U++ developer or experienced user. However, I guess that for average user, adding another package to assembly is not that simple.

Anyway, in any case, I believe that it is important to mark them "Bazaar" in the info line, because such packages will appear among uppsrc packages...

Mirek
Re: Bazaar.... [message #15213 is a reply to message #15200] Thu, 10 April 2008 02:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12096
Registered: November 2005
Ultimate Member
mr_ped wrote on Tue, 08 April 2008 15:51


I think the Bazaar nest alone is excellent way to let U++ users know: "this" package is not fully supported by Core developers, so everyone can evaluate the risk of using it.



Nest is not enough. Nests are not displayed when adding "uses".

Mirek
Re: Bazaar.... [message #15222 is a reply to message #15212] Thu, 10 April 2008 12:24 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1259
Registered: September 2007
Senior Contributor
luzr wrote on Thu, 10 April 2008 02:31


Anyway, in any case, I believe that it is important to mark them "Bazaar" in the info line, because such packages will appear among uppsrc packages...




I agree. I often get confused when I look for packages that I know they're bazaar ones and I find them intermixed with upp ones.
Maybe (but that would be a bit more complicated...) would be better to have packages separated by nest group in package manager, with a separator between :
UPPSRC :
  ide
  core
  ......
BAZAAR ;
  rasterctrl
  otherstuffs
  ......
MYAPPS :
  myfirstpackage
  mysecondpackage
  ....


So we could always see to what belongs a package.

Ciao

Max
Re: Bazaar.... [message #15232 is a reply to message #15222] Thu, 10 April 2008 18:03 Go to previous message
mirek is currently offline  mirek
Messages: 12096
Registered: November 2005
Ultimate Member
Interesting idea.

Mirek
Previous Topic: Dev 712 or 2008.1 beta?
Next Topic: Not all GUI UPP project files have NOGTK configuration
Goto Forum:
  


Current Time: Tue Nov 12 20:14:21 CET 2019

Total time taken to generate the page: 0.01705 seconds