Xfce development and release model

[Jannis Pohlmann-3]

Hey all,

for the last two days, Stephan and I have been busy thinking about how
to improve the development and release process after we've switched to
git. Today we wrote these ideas down in a document available in our
wiki.

There are a number of questions and problems that came up again and
again every now and then, like

    * What are the core components of Xfce?
    * How often do we want to release and in what fashion?
    * Who's in charge of the release process?
    * What dependency versions do we depend on?
    * When are feature-freeze, string-freeze, code-freeze and thelike?
    * How many pre-releases should we do and how do we call them?
    * What do we use as a replacement for SVN revision versioning with
      Git?

Another important question is how can we reduce the amount of stress
and work for the individuals involved in development and releasing?

The following document tries to answer most of these questions and
gives detailed explanations on how we think the entire development and
release process can be improved significantly.

There are a number of reasons why we think the approach described in
the document meets these goals:

  * work is distributed among people involved in the project
  * blocker bugs are clearly defined
  * individual releases during the development and maintenance process
    allow people to publish bugfixes more easily and make the overall
    release process less painful
  * releasing often reduces deltas and thus helps distributions and
    users follow the development process more easily. It also helps to
    trace regressions.
  * it includes a proper definition of the Xfce core
  * the planning phase reduces confusion about dependency versions and
    dependencies in general. It serves as a solid foundation for every
    phase of the release cycle
  * it's more fun to develop if you know what you're working towards (a
    fixed schedule helps to focus)

So, without further ado, here's the document:

  http://wiki.xfce.org/releng/release-policy

Cheers,
Stephan and Jannis


_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Jannis Pohlmann-3]

On Wed, 27 May 2009 18:04:08 +0200
Jannis Pohlmann <jannis@...> wrote:

> Hey all,
>
> for the last two days, Stephan and I have been busy thinking about how
> to improve the development and release process after we've switched to
> git. Today we wrote these ideas down in a document available in our
> wiki.
>
> There are a number of questions and problems that came up again and
> again every now and then, like
>
>     * What are the core components of Xfce?
>     * How often do we want to release and in what fashion?
>     * Who's in charge of the release process?
>     * What dependency versions do we depend on?
>     * When are feature-freeze, string-freeze, code-freeze and thelike?
>     * How many pre-releases should we do and how do we call them?
>     * What do we use as a replacement for SVN revision versioning with
>       Git?
>
> Another important question is how can we reduce the amount of stress
> and work for the individuals involved in development and releasing?
>
> The following document tries to answer most of these questions and
> gives detailed explanations on how we think the entire development and
> release process can be improved significantly.
>
> There are a number of reasons why we think the approach described in
> the document meets these goals:
>
>   * work is distributed among people involved in the project
>   * blocker bugs are clearly defined
>   * individual releases during the development and maintenance process
>     allow people to publish bugfixes more easily and make the overall
>     release process less painful
>   * releasing often reduces deltas and thus helps distributions and
>     users follow the development process more easily. It also helps to
>     trace regressions.
>   * it includes a proper definition of the Xfce core
>   * the planning phase reduces confusion about dependency versions and
>     dependencies in general. It serves as a solid foundation for every
>     phase of the release cycle
>   * it's more fun to develop if you know what you're working towards
> (a fixed schedule helps to focus)
>
> So, without further ado, here's the document:
>
>   http://wiki.xfce.org/releng/release-policy

Oh, yeah, and please, please, please give comments and feedback!

  - Jannis


_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[David Mohr-8]

On Wed, May 27, 2009 at 10:07 AM, Jannis Pohlmann <jannis@...> wrote:
> On Wed, 27 May 2009 18:04:08 +0200
> Jannis Pohlmann <jannis@...> wrote:
...
>>   http://wiki.xfce.org/releng/release-policy
>
> Oh, yeah, and please, please, please give comments and feedback!

It's not very clear to me what the purpose of the "ELS" is. Why not
just apply bug fixes in the master branch?

~David
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Brian J. Tarricone-3]

Jannis Pohlmann wrote:
>> So, without further ado, here's the document:
>>
>>   http://wiki.xfce.org/releng/release-policy
>
> Oh, yeah, and please, please, please give comments and feedback!

-ETOOMUCHTEXT  ^_~

Seriously, though... this looks really well thought-out.  When I read
the bit about the ELS, I was a little hesitant, but it makes sense.
We've never really done a proper code-freeze before, and that's
definitely made the release process harder on the release manager at times.

Personally, I'd probably rearrange that to eliminate the ELS branch
(branch xfce-x.y at code freeze, xfce-x.y only gets i18n updates, final
release is tagged from xfce-x.y, and master gets bugfixes, which are
merged into xfce-x.y after final release).  But with that setup you have
to commit i18n updates to both master and xfce-x.y between code freeze
and final release.  So it's really one thing or another: either you have
an extra branch to worry about, or you don't have the extra branch, but
you have to check i18n updates into two branches at once for a little
while.  I guess since git branches are so easy, the extra branch method
is probably easiest to keep track of overall.

(I think "Early Lifetime Support" is a kinda silly name, but that's just
bike-shedding.)

Some questions/comments:

* Core components:

1.  I know this is a touchy subject, but I think we should get this out
of the way sooner rather than later.

2.  Non-core components are of course free to "play along" with the
release process and time their major feature release with an Xfce x.y.0
release.

* Planning phase:

1.  What happens if a maintainer doesn't have time to finish all the
features planned?

2.  What happens if a maintainer "under-plans" and has time to add
features thought of after the planning phase is over?

3.  What happens if a maintainer isn't available for the planning phase?
  Certainly we can work around the expected things (like vacations,
business trips, and exam periods), but most/all of us have other
jobs/lives outside Xfce and it's possible that things might come up that
could take us away for a week or more.

* Development phase:

1.  What happens if components A and B depend on component C, and
component C is going to have an API break during development?  Say the
maintainer of component A does a release to use the new API at the same
time component C gets released, but the maintainer of component B is
unable to for whatever reason.  How do we handle this?  (Ideally all
dependencies allow parallel installs of incompatible versions, but I
don't know if we can rely on this, esp if component C isn't an Xfce module.)

* Release team:

1.  What happens when we can't find enough people to do all these jobs?
  (QA Official might be difficult; it's a thankless job that isn't
really interesting or fun.)

* Blocking bugs:

1.  Might want to discuss what happens if a blocker can't be resolved in
a timely manner.  Do we try to back out the entire feature that we think
might be causing the bug?  What if a bisect puts the offending commit
*very* far back in the history such that backing it out is difficult?
(Ideally this wouldn't happen; one would think that a bug bad enough to
be a blocker would be noticed soon after it enters the tree.)

* Maintenance process:

1.  If maint releases are required to be API/ABI stable, are we
encouraging major feature releases to break API/ABI?  At least since
4.0.0, the only ABI breaks have been unfortunate accidents that we
couldn't fix after the fact.

That's all for now, I guess.

        -b
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Stephan Arts-2]

On Thu, May 28, 2009 at 6:41 AM, Brian J. Tarricone <brian@...> wrote:

> Jannis Pohlmann wrote:
>>>
>>> So, without further ado, here's the document:
>>>
>>>  http://wiki.xfce.org/releng/release-policy
>>
>> Oh, yeah, and please, please, please give comments and feedback!
>
> -ETOOMUCHTEXT  ^_~
>
> Seriously, though... this looks really well thought-out.  When I read the
> bit about the ELS, I was a little hesitant, but it makes sense. We've never
> really done a proper code-freeze before, and that's definitely made the
> release process harder on the release manager at times.
>
> Personally, I'd probably rearrange that to eliminate the ELS branch (branch
> xfce-x.y at code freeze, xfce-x.y only gets i18n updates, final release is
> tagged from xfce-x.y, and master gets bugfixes, which are merged into
> xfce-x.y after final release).  But with that setup you have to commit i18n
> updates to both master and xfce-x.y between code freeze and final release.
>  So it's really one thing or another: either you have an extra branch to
> worry about, or you don't have the extra branch, but you have to check i18n
> updates into two branches at once for a little while.  I guess since git
> branches are so easy, the extra branch method is probably easiest to keep
> track of overall.
>
> (I think "Early Lifetime Support" is a kinda silly name, but that's just
> bike-shedding.)
>
> Some questions/comments:
>
> * Core components:
>
> 1.  I know this is a touchy subject, but I think we should get this out of
> the way sooner rather than later.
>
> 2.  Non-core components are of course free to "play along" with the release
> process and time their major feature release with an Xfce x.y.0 release.
>
> * Planning phase:
>
> 1.  What happens if a maintainer doesn't have time to finish all the
> features planned?

Then the feature doesn't get merged, we release, and it will probably
enter the next X.Y release. You simply can't force people to work on
things they don't have time for. And since we can't anticipate when we
are going to have time, having partially finished code in a branch is
less of a problem then having it in master. (like what used to happen
with svn-trunk)

>
> 2.  What happens if a maintainer "under-plans" and has time to add features
> thought of after the planning phase is over?

That's really up to the maintainer, he can implement the feature in a
branch, and decide if he wants to merge it before the feature-freeze
or let it rest there until after the X.Y release. Personally, I prefer
the last approach, because we have seen the occasional 'ooh, this
feature should go in too' last-minute breakage... And with a tight
schedule, it is not a real problem if it doesn't get in, with 3
releases in 2 years, that feature will be released sooner then it used
to anyways ^_~


> 3.  What happens if a maintainer isn't available for the planning phase?
>  Certainly we can work around the expected things (like vacations, business
> trips, and exam periods), but most/all of us have other jobs/lives outside
> Xfce and it's possible that things might come up that could take us away for
> a week or more.

We could have a 2w 'transition-phase' where, in case a developer
wasn't around during the planning-phase, he can still propose a
different set of dependencies based on the features he wants to
implement.

If no consensus is reached, or these 2w have passed. The feature
should be optional, like we have sound-settings now, which only work
with libcanberra+gtk2.14.

>
> * Development phase:
>
> 1.  What happens if components A and B depend on component C, and component
> C is going to have an API break during development?  Say the maintainer of
> component A does a release to use the new API at the same time component C
> gets released, but the maintainer of component B is unable to for whatever
> reason.  How do we handle this?  (Ideally all dependencies allow parallel
> installs of incompatible versions, but I don't know if we can rely on this,
> esp if component C isn't an Xfce module.)

If one of us is the author of C, then we can anticipate the breakage,
reducing the risk of a useless component B. If we are not the author
of C, then there is probably little we can do about it. But the same
is true today, if someone breaks GTK+ or D-BUS, we're screwed.

-
Cheers,
Stephan
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Nick Schermer]

Few notes/questions:

- In the branch image there is 'No change', looks a bit weird. You can
still commit bugfixes and translations in master while working in a
feature branch right?

- There is, 'The release team always picks the latest available
development release of each component for pre-releases and the final
release', should be latest stable release I guess?

- I'm not really a fan of the ELS branch, personally I would prefer a
small period after the final tag where only bugfixes and translation
updates are allowed, like we did with Xfce 4.6.0 -> 4.6.1, then create
a stable branch from the 4.6.1 master.

- Maybe mention the buildbot somewhere, which monitors the master
branch all the time. Maybe even an (unofficial) rule that no feature
branches are merged in master while the buildbot reports a broken
master (fix before you continue!).

Nick
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Brian J. Tarricone]

On 05/28/2009 02:33 AM, Nick Schermer wrote:
> Few notes/questions:
>
> - In the branch image there is 'No change', looks a bit weird. You can
> still commit bugfixes and translations in master while working in a
> feature branch right?

That raises another question: do we have (or want to have) a bugfix
policy during development cycles?  Should:

1. Bugfixes first be checked into master, and then be pushed out to the
xfce-x.y branch after testing?  (Only viable if master hasn't diverged
too much from xfce-x.y.)

2. Bugfixes be checked into both master and xfce-x.y (assuming they
apply to both) at the same time?

3. Bugfixes be checked into xfce-x.y only (assuming that bugs are
reported against the stable release), and then periodically merged into
master when convenient?

This might just be "maintainer's preference," but it might be useful to
discuss pros and cons of the various styles.

> - There is, 'The release team always picks the latest available
> development release of each component for pre-releases and the final
> release', should be latest stable release I guess?

No, I think that's right... we're talking about gearing up for a new
xfce-x.y.0 feature release.  The pre-releases for that should come from
devel releases (which are made from master), since that's what will get
released as xfce-x.y.0 final.

> - I'm not really a fan of the ELS branch, personally I would prefer a
> small period after the final tag where only bugfixes and translation
> updates are allowed, like we did with Xfce 4.6.0 ->  4.6.1, then create
> a stable branch from the 4.6.1 master.

Well that's something else entirely...  what you propose is to do away
with the code freeze entirely.  The idea of ELS is to collect bug fixes
while master is in code freeze.

> - Maybe mention the buildbot somewhere, which monitors the master
> branch all the time. Maybe even an (unofficial) rule that no feature
> branches are merged in master while the buildbot reports a broken
> master (fix before you continue!).

Yeah, good idea... heh, though I wonder how useful it is for the
buildbot to only monitor master.  Seems like it's going to be doing a
lot of busywork since master should remain mostly untouched (aside from
bugfixes) during dev cycles.  The only time master gets any changes that
are probably worth build testing are when a feature branch gets merged
in.  It might be nice to monitor feature branches while they're being
worked on in order to catch issues earlier.  Dunno how feasible that is,
though.

        -b
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Nick Schermer]

2009/5/28 Brian J. Tarricone <bjt23@...>:

> On 05/28/2009 02:33 AM, Nick Schermer wrote:
>>
>> Few notes/questions:
>>
>> - In the branch image there is 'No change', looks a bit weird. You can
>> still commit bugfixes and translations in master while working in a
>> feature branch right?
>
> That raises another question: do we have (or want to have) a bugfix policy
> during development cycles?  Should:
>
> 1. Bugfixes first be checked into master, and then be pushed out to the
> xfce-x.y branch after testing?  (Only viable if master hasn't diverged too
> much from xfce-x.y.)

I'd prefer this, commit in master test it a bit (buildbot) and then
cherrypick into the stable branch. (Ofcourse only if the bug applies
to master, code could have changed in master by a feature branch).

>> - There is, 'The release team always picks the latest available
>> development release of each component for pre-releases and the final
>> release', should be latest stable release I guess?
>
> No, I think that's right... we're talking about gearing up for a new
> xfce-x.y.0 feature release.  The pre-releases for that should come from
> devel releases (which are made from master), since that's what will get
> released as xfce-x.y.0 final.

But a maintainer is also allowed to do independent releases, so assume
I'm releasing a devel version of the panel for a new experimental
feature that needs testing, then I don't want that to show up in the
pre or final release.

>> - I'm not really a fan of the ELS branch, personally I would prefer a
>> small period after the final tag where only bugfixes and translation
>> updates are allowed, like we did with Xfce 4.6.0 ->  4.6.1, then create
>> a stable branch from the 4.6.1 master.
>
> Well that's something else entirely...  what you propose is to do away with
> the code freeze entirely.  The idea of ELS is to collect bug fixes while
> master is in code freeze.

O yeah sorry, misreading. I now get the code-freeze thing.

Nick
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Jannis Pohlmann-3]

Hey,

On Wed, 27 May 2009 18:04:08 +0200
Jannis Pohlmann <jannis@...> wrote:

> So, without further ado, here's the document:
>
>   http://wiki.xfce.org/releng/release-policy

I've updated the document to clarify a few more things about which
concerns were raised:

  * the planning phase is now 2+2 weeks, allowing maintainers who were
    unavailable the first 2 weeks to request dependency changes later

  * after the 2+2 weeks planning phase, there is a dependency freeze
    which means no further changes to dependencies may be made, unless
    they are optional

  * API breakage in the development phase should be communicated and
    people should prepare other components for a release that
    introduces API breakage so that they can soon return to a
    release-ready state

  * there's a 2-days code freeze before each pre-release

  * there's a UI freeze at the same time as string freeze

  * bugfixes and release-critical changes may be committed to master
    during code freeze if, and only if they are signed off the release
    manager

I'll reply to the rest of the feedback soon. Please note that the
graphics on the page are currently out of date and the maintenance
process still has to be defined more detailed (like the support time
of maintenance cycles).

  - Jannis


_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Jannis Pohlmann-3]

On Wed, 27 May 2009 21:41:15 -0700
"Brian J. Tarricone" <brian@...> wrote:

(snip)

> 3.  What happens if a maintainer isn't available for the planning
> phase? Certainly we can work around the expected things (like
> vacations, business trips, and exam periods), but most/all of us have
> other jobs/lives outside Xfce and it's possible that things might
> come up that could take us away for a week or more.

This is addressed in the current state of the document (see my other
mail).

> * Development phase:
>
> 1.  What happens if components A and B depend on component C, and
> component C is going to have an API break during development?  Say
> the maintainer of component A does a release to use the new API at
> the same time component C gets released, but the maintainer of
> component B is unable to for whatever reason.  How do we handle
> this?  (Ideally all dependencies allow parallel installs of
> incompatible versions, but I don't know if we can rely on this, esp
> if component C isn't an Xfce module.)

I added the following paragraph to the development releases section, I
hope that is more clear:

"New features breaking APIs or other core components should be
communicated. Maintainers are suggested to prepare other components for
these features in a separate branch before including the features in a
new development release. That way the other components retain their
release-ready state."

> * Release team:
>
> 1.  What happens when we can't find enough people to do all these
> jobs? (QA Official might be difficult; it's a thankless job that
> isn't really interesting or fun.)

Only release manager and QA Official are mandatory. But I doubt we'll
have any problems in finding people to help out with the website or
other little jobs as release assistants.

> * Blocking bugs:
>
> 1.  Might want to discuss what happens if a blocker can't be resolved
> in a timely manner.  Do we try to back out the entire feature that we
> think might be causing the bug?  What if a bisect puts the offending
> commit *very* far back in the history such that backing it out is
> difficult? (Ideally this wouldn't happen; one would think that a bug
> bad enough to be a blocker would be noticed soon after it enters the
> tree.)

I'd say that's about the only situation where a blocker could delay a
release.

> * Maintenance process:
>
> 1.  If maint releases are required to be API/ABI stable, are we
> encouraging major feature releases to break API/ABI?  At least since
> 4.0.0, the only ABI breaks have been unfortunate accidents that we
> couldn't fix after the fact.

I've changed that the description to say "there may be no API/ABI
changes in maintenance releases compared to the corresponding final
release of the Xfce core desktop."

Of course there may be functions added to libraries in development
releases. Dunno if that was what you were referring to.

  - Jannis


_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Jannis Pohlmann-3]

On Thu, 28 May 2009 03:43:39 -0700
"Brian J. Tarricone" <bjt23@...> wrote:

> On 05/28/2009 02:33 AM, Nick Schermer wrote:
> > Few notes/questions:
> >
> > - In the branch image there is 'No change', looks a bit weird. You
> > can still commit bugfixes and translations in master while working
> > in a feature branch right?

That's just an example. The Feature2 branch is just a short lifetime
branch while there are commits made to master during Feature1.

> That raises another question: do we have (or want to have) a bugfix
> policy during development cycles?  Should:
>
> 1. Bugfixes first be checked into master, and then be pushed out to
> the xfce-x.y branch after testing?  (Only viable if master hasn't
> diverged too much from xfce-x.y.)

I think I prefer this one. Usually, small fixes are only committed if
they seem to actually *fix* the problem. But in case of more
complex fixes, a bit of testing before merging it into the stable
branch can't hurt.

> 2. Bugfixes be checked into both master and xfce-x.y (assuming they
> apply to both) at the same time?
>
> 3. Bugfixes be checked into xfce-x.y only (assuming that bugs are
> reported against the stable release), and then periodically merged
> into master when convenient?
>
> This might just be "maintainer's preference," but it might be useful
> to discuss pros and cons of the various styles.

Yeah, agreed.

> > - There is, 'The release team always picks the latest available
> > development release of each component for pre-releases and the final
> > release', should be latest stable release I guess?
>
> No, I think that's right... we're talking about gearing up for a new
> xfce-x.y.0 feature release.  The pre-releases for that should come
> from devel releases (which are made from master), since that's what
> will get released as xfce-x.y.0 final.

Yep, it's correct. I changed it to "Each of these releases has to
include the latest development releases of all components (or stable,
if there were no development releases since the last stable release) of
the Xfce core desktop."

> > - I'm not really a fan of the ELS branch, personally I would prefer
> > a small period after the final tag where only bugfixes and
> > translation updates are allowed, like we did with Xfce 4.6.0 ->
> > 4.6.1, then create a stable branch from the 4.6.1 master.

I don't really like that. I don't feel like pausing the entire
development for two or more weeks (in case there are any blockers) just
because we don't branch earlier.

> Well that's something else entirely...  what you propose is to do
> away with the code freeze entirely.  The idea of ELS is to collect
> bug fixes while master is in code freeze.

Yep, exactly. It's a very nice way to work on fixes in parallel to the
release being performed (possibly by someone else).

> > - Maybe mention the buildbot somewhere, which monitors the master
> > branch all the time. Maybe even an (unofficial) rule that no feature
> > branches are merged in master while the buildbot reports a broken
> > master (fix before you continue!).
>
> Yeah, good idea... heh, though I wonder how useful it is for the
> buildbot to only monitor master.  Seems like it's going to be doing a
> lot of busywork since master should remain mostly untouched (aside
> from bugfixes) during dev cycles.  The only time master gets any
> changes that are probably worth build testing are when a feature
> branch gets merged in.  It might be nice to monitor feature branches
> while they're being worked on in order to catch issues earlier.
> Dunno how feasible that is, though.

Hmmm, maybe. I think I'd prefer to just let it build master because
that's what we're using for releases and the 10 weeks release phase
should be more than enough time to fix compile issues reported by
buildbot.

  - Jannis


_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Jannis Pohlmann-3]

On Thu, 28 May 2009 12:59:32 +0200
Nick Schermer <nickschermer@...> wrote:

> 2009/5/28 Brian J. Tarricone <bjt23@...>:
> > On 05/28/2009 02:33 AM, Nick Schermer wrote:
> >>
> >> Few notes/questions:
> >>
> >> - In the branch image there is 'No change', looks a bit weird. You
> >> can still commit bugfixes and translations in master while working
> >> in a feature branch right?
> >
> > That raises another question: do we have (or want to have) a bugfix
> > policy during development cycles?  Should:
> >
> > 1. Bugfixes first be checked into master, and then be pushed out to
> > the xfce-x.y branch after testing?  (Only viable if master hasn't
> > diverged too much from xfce-x.y.)
>
> I'd prefer this, commit in master test it a bit (buildbot) and then
> cherrypick into the stable branch. (Ofcourse only if the bug applies
> to master, code could have changed in master by a feature branch).
>
> >> - There is, 'The release team always picks the latest available
> >> development release of each component for pre-releases and the
> >> final release', should be latest stable release I guess?
> >
> > No, I think that's right... we're talking about gearing up for a new
> > xfce-x.y.0 feature release.  The pre-releases for that should come
> > from devel releases (which are made from master), since that's what
> > will get released as xfce-x.y.0 final.
>
> But a maintainer is also allowed to do independent releases, so assume
> I'm releasing a devel version of the panel for a new experimental
> feature that needs testing, then I don't want that to show up in the
> pre or final release.

Don't release then. Only release what's finished (I'd even say only
merge into master what's finished) and what you really want to be part
of the next release.

> >> - I'm not really a fan of the ELS branch, personally I would
> >> prefer a small period after the final tag where only bugfixes and
> >> translation updates are allowed, like we did with Xfce 4.6.0 ->
> >>  4.6.1, then create a stable branch from the 4.6.1 master.
> >
> > Well that's something else entirely...  what you propose is to do
> > away with the code freeze entirely.  The idea of ELS is to collect
> > bug fixes while master is in code freeze.
>
> O yeah sorry, misreading. I now get the code-freeze thing.

Cool. Another thing about the code freeze: I could imagine that it
would be nice to have a special permissions hook script for code freeze
which only allows commits signed off by the release manager. It's
really easy to implement and could keep us from becoming sloppy and
less strict about the code freeze.

I've added this to the document: "The code freeze and its exceptions
are supported by commit hooks. There is an update hook which doesn't
allow any changes to master unless they are signed off by the release
manager."

  - Jannis


_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Nick Schermer]

To bring this up again... I'd like to release a 0.3 alpha version of
the terminal somewhere at the end of this week. The question is,
should I treat the Terminal as part of the goodies or core components?

Until now there has been a release of the terminal together with the
Xfce releases and the new release policy allows development releases
during the dev. phase, but how? Where do I upload the tarballs if it's
a core component?

Cheers,
Nick
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Jannis Pohlmann-3]

On Tue, 7 Jul 2009 11:15:01 +0200
Nick Schermer <nickschermer@...> wrote:

> To bring this up again... I'd like to release a 0.3 alpha version of
> the terminal somewhere at the end of this week. The question is,
> should I treat the Terminal as part of the goodies or core components?
>
> Until now there has been a release of the terminal together with the
> Xfce releases and the new release policy allows development releases
> during the dev. phase, but how? Where do I upload the tarballs if it's
> a core component?

You are free to release it independently of the rest of Xfce. It's true
though that we don't have a plan on how to organize the release
archives yet. Did we decide anything on the goodie/core status of
Terminal by the way? I think Brian listed it as a goodie in his git
repository structure proposal.

Releasing it as a goodie would be the least painful way at this point
because the infrastructure for that is in place. But we will soon need
reorganize the release archive because I'm planning to release tumbler
and probably garcon (aka libxfce4menu) later this summer, and those are
definitely not goodies.

Basically, instead of the current

  /xfce-4.4.0
    src/
    fat_tarballs/
    installers/
  /xfce-4.6.0
    src/
    fat_tarballs/
    installers/
  /xfce-4.6.1
    src/
    fat_tarballs/
    installers/

I could imagine using the same layout as for the git repositories:

  /xfce
    exo/
      0.3/
        exo-0.3.100.tar.bz2
        exo-0.3.101.tar.bz2
      0.4/
        exo-0.4.0.tar.bz2
    xfwm4/
      4.6/
        xfwm4-4.6.0.tar.bz2
        xfwm4-4.6.1.tar.bz2
      4.7/
        xfwm4-4.7.0.tar.bz2
  /goodies
    terminal/
      0.2/
        ...
  /libs
    garcon/
      0.1/
        ...
      0.2/
        ...

Then the question is: what to do with Xfce group releases? GNOME does
something like this:

  /gnome (well, they have it split up into bindings/, platform/ etc.)
    2.26.0/
      sources/
        <all tarballs of the release are in here>
    2.26.1/
      sources/
        <all tarballs of the release are in here>
  /sources
    GConf/
      0.1/
        <tarballs>
      0.2/
        <tarballs>
    nautilus/
      ...

We could do something similar and use:

  /xfce
    4.4.0/
      fat_tarballs/
      src/
      installers/
    4.6.0/
      fat_tarballs/
      src/
      installers/
    4.6.1/
      ...
  /src
    xfce/
      exo/
        0.3/
          exo-0.3.100.tar.bz2
          exo-0.3.101.tar.bz2
        0.4/
          exo-0.4.0.tar.bz2
      xfwm4/
        4.6/
          xfwm4-4.6.0.tar.bz2
          xfwm4-4.6.1.tar.bz2
        4.7/
          ...
   goodies/
     terminal/
        0.2/
          ...
        0.3/
          ...
    libs/
      garcon/
        0.1/
          ...
        0.2/
          ...

We can already do this NOW (together with updating the website) and
have someone upload tarballs manually until we have something similar
to the goodies release manager.

Toughts?

  - Jannis


_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Stephan Arts-2]

On Tue, Jul 7, 2009 at 12:49 PM, Jannis Pohlmann<jannis@...> wrote:

> On Tue, 7 Jul 2009 11:15:01 +0200
> Nick Schermer <nickschermer@...> wrote:
>
>> To bring this up again... I'd like to release a 0.3 alpha version of
>> the terminal somewhere at the end of this week. The question is,
>> should I treat the Terminal as part of the goodies or core components?
>>
>> Until now there has been a release of the terminal together with the
>> Xfce releases and the new release policy allows development releases
>> during the dev. phase, but how? Where do I upload the tarballs if it's
>> a core component?
>
> You are free to release it independently of the rest of Xfce. It's true
> though that we don't have a plan on how to organize the release
> archives yet. Did we decide anything on the goodie/core status of
> Terminal by the way? I think Brian listed it as a goodie in his git
> repository structure proposal.
>
> Releasing it as a goodie would be the least painful way at this point
> because the infrastructure for that is in place. But we will soon need
> reorganize the release archive because I'm planning to release tumbler
> and probably garcon (aka libxfce4menu) later this summer, and those are
> definitely not goodies.
>
> Basically, instead of the current
>
>  /xfce-4.4.0
>    src/
>    fat_tarballs/
>    installers/
>  /xfce-4.6.0
>    src/
>    fat_tarballs/
>    installers/
>  /xfce-4.6.1
>    src/
>    fat_tarballs/
>    installers/
>
> I could imagine using the same layout as for the git repositories:
>
>  /xfce
>    exo/
>      0.3/
>        exo-0.3.100.tar.bz2
>        exo-0.3.101.tar.bz2
>      0.4/
>        exo-0.4.0.tar.bz2
>    xfwm4/
>      4.6/
>        xfwm4-4.6.0.tar.bz2
>        xfwm4-4.6.1.tar.bz2
>      4.7/
>        xfwm4-4.7.0.tar.bz2
>  /goodies
>    terminal/
>      0.2/
>        ...
>  /libs
>    garcon/
>      0.1/
>        ...
>      0.2/
>        ...
>
> Then the question is: what to do with Xfce group releases? GNOME does
> something like this:
>
>  /gnome (well, they have it split up into bindings/, platform/ etc.)
>    2.26.0/
>      sources/
>        <all tarballs of the release are in here>
>    2.26.1/
>      sources/
>        <all tarballs of the release are in here>
>  /sources
>    GConf/
>      0.1/
>        <tarballs>
>      0.2/
>        <tarballs>
>    nautilus/
>      ...
>
> We could do something similar and use:
>
>  /xfce
>    4.4.0/
>      fat_tarballs/
>      src/
>      installers/
>    4.6.0/
>      fat_tarballs/
>      src/
>      installers/
>    4.6.1/
>      ...
>  /src
>    xfce/
>      exo/
>        0.3/
>          exo-0.3.100.tar.bz2
>          exo-0.3.101.tar.bz2
>        0.4/
>          exo-0.4.0.tar.bz2
>      xfwm4/
>        4.6/
>          xfwm4-4.6.0.tar.bz2
>          xfwm4-4.6.1.tar.bz2
>        4.7/
>          ...
>   goodies/
>     terminal/
>        0.2/
>          ...
>        0.3/
>          ...
>    libs/
>      garcon/
>        0.1/
>          ...
>        0.2/
>          ...
>
> We can already do this NOW (together with updating the website) and
> have someone upload tarballs manually until we have something similar
> to the goodies release manager.
>
> Toughts?

+1

-
Stephan
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Landry Breuil-4]

On Tue, Jul 7, 2009 at 11:15 AM, Nick Schermer<nickschermer@...> wrote:
> To bring this up again... I'd like to release a 0.3 alpha version of
> the terminal somewhere at the end of this week. The question is,
> should I treat the Terminal as part of the goodies or core components?

Oh yes, please a terminal release.. we want to test all the bugfixes
and features you added :)
(Btw, thanks for taking care of terminal)

Just a minor annoyance.. it relies on libxfce4ui, which hasn't been
released yet.
So you probably have to release a 4.5.0 version of it, not versionned
together with the
rest of core xfce libs...

Landry
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Nick Schermer]

2009/7/7 Landry Breuil <landry.breuil@...>:
> Just a minor annoyance.. it relies on libxfce4ui, which hasn't been
> released yet.
> So you probably have to release a 4.5.0 version of it, not versionned
> together with the
> rest of core xfce libs...

I know. I'll include the xfce titled dialog code until there is a
release of libxfce4ui.

Nick
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev