[Panel-devel] RFC: release management strategy

Jos Poortvliet jos at mijnkamer.nl
Thu Aug 30 12:28:29 CEST 2007


On 8/30/07, Kevin Ottens <ervin at kde.org> wrote:
>
> Le mercredi 29 août 2007, Aaron J. Seigo a écrit :
> > i've never really liked kdeaddons, either. so here's my proposal:
> >
> > - we keep the set of items in kdebase/workspace/plasma *minimal*. these
> > should be core functionality items only. i'd like to have an irc meeting
> in
> > 2 weeks time to settle on which those will be.
>
> Sounds fair, you know that I'd like to see kdebase minimal anyway,
> providing
> the basic desktop features, so I'm clearly biased here.
>
> > - we create extragear/plasma/ with subdirs for dataengines/, runners/,
> > applets/, plasmoids/, scriptengines/ and possibly animators/ (if any new
> > ones appear =). people move their own work as they want into
> > extragear/plasma/. plasmoids/ would house non-c++ packages. we will
> cover
> > which items to move over now at that irc meeting.
> >
> > - we create a place for sample applets; perhaps in extragear as well?
> e.g.
> > extragear/plasma/samples/ with all the subdirs under there? i don't want
> to
> > lose all the samples; i think they are valuable and should be
> maintained.
> > they shouldn't be installed, or shipped, by default but be there for
> > documentary and educational purposes.
>
> Maybe it's better to keep them along the plasma libraries then? As a
> developer
> I like to find the examples with the code of the library I'm about to use
> (phonon and solid follow this pattern).
>
> > - there will be *no* plasma stuff in kdeaddons. this could be seen as my
> > desire to kill kdeaddons outright, which would be accurate. ;)
> >
> > then releases will happen like this:
> >
> > - everything gets released with each KDE release, extragear included
>
> w00t!
>
> > - we do a source only snapshot release of plasma itself for our more
> > devoted testers one a month. this is assuming KDE itself doesn't get
> into
> > this game so we don't have to.
>
> Hmmm, reminds me something... :-p
>
> > but even if KDE as a whole doesn't do
> > periodic snapshots, i want to for plasma. maybe plasma could serve as a
> > test case here for the rest of KDE if need be
>
> Looks fair.
>
> > - we do a snapshot release of extragear every 2 weeks, hopefully as
> proper
> > releases including binaries for as many platforms as possible. we need
> to
> > look into availability of services such as OpenSUSE's build system as i
> > really don't want to set up and maintain a network of systems ourselves
> =)
>
> I'm not sure about the 2 weeks thing, at this rate (and because of our
> current
> organisation where we definitely don't branch enough) you'll end up
> snapshoting non building or broken stuff.
>
> Actually, the 1 month snapshot rate we discussed a while ago was my
> pessimistic view because of our current way of working. If we had a SCM
> that
> allows us to branch more (means cheap branching, fast switching, both way
> merges that don't kill the history) then push changes in the main when
> ready
> I'd push to two weeks even for KDE itself.
>
> > what this means is that we can get people trying out new addons all the
> > time and keep the GHNS2 constantly repo fresh. it also means that kde
> > releases are full of all the plasma goodies up to that point in time.
> > hooray.
>
> With regular snapshots like this you probably want to be able to separate
> the "stable build", from the "snapshot builds" when the user retrieves the
> stuff. Does GHNS2 provide this kind of information? (I'm really clueless
> regarding GHNS2 features)
>
> > proposed irc meeting day: saturday sept 8th. please rsvp =)
>
> Right, any time during the day? or you envision a 24h meeting? ;-)


What, something wrong with that? Where are your hardcore feelings?


(sorry, but I couldn't resist. Usually, this is Wade's job, I know... Sorry
to step on your toes, W!)

Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20070830/0784d0c1/attachment.html 


More information about the Panel-devel mailing list