[Development] QtWindowsExtras

[Oswald Buddenhagen]

On Thu, Feb 14, 2013 at 11:01:31PM +0000, Laszlo Papp wrote:
> On Thu, Feb 14, 2013 at 9:16 PM, Knoll Lars <Lars.Knoll at digia.com> wrote:
> > Well, I already gave that my approval some days ago in another thread.
> >
> > I've now created the repository.
> > ssh://codereview.qt-project.org:29418/qt/qtwinextras.git.
> >
ehm. yeah. and i fixed the setup. ;) 

the project is currently not CI-controlled. is this expected to change
soon?

> Lars, just double checking for making sure: you meant to create
> qt/qtwinextras or more like playground as playground/qtmacextras?
> 
this question is actually why i didn't create the project to start with
- x11extras is under qt/, while macextras is in playground/.

anyway, i'll use this to raise a general point: i think the idea to put
new projects physically under playground/ and then actually moving them
upon graduation is counterproductive:
- as we know, gerrit is too limited to actually allow it, and nobody has
  bothered yet to do the manual work for the already graduated project
  (i can give it a shot, but don't shout if i accidentally take down the
  system ... (i'm positive it would be only temporary :D)).
- changing the location of the repository is slightly disruptive
- we have no process to "un-graduate" projects. think qtpim and the
  sorts. this is "pr-wise unfair" to the projects which are actually
  stable (but still must stay in playground for technical reasons).

therefore i'd like to propose the following alteration of the process:
- nothing changes for projects which are not meant to graduate on their
  own. think playground/qtbinaryjson.
- all other projects are created in the hierarchy they are aiming for
- their maturity is represented solely by some external meta
  information:
  - a wiki page (do we have one which could serve this already?)
  - the set of modules init-repository would clone by default (see also
    https://codereview.qt-project.org/41547 and
    https://codereview.qt-project.org/41548 (i plan to actually add more
    in a later commit))
    - alternatively, it would be possible to create a separate branch of
      the supermodule which includes more submodules than the mainline
      branches. it would be bothersome to maintain this, though.
- projects which are positively abandoned could be physically moved to a
  separate "namespace" (pending technical obstacles of actually moving)

discuss!