Re: Defining GNOME software (finally)

[Allan Day]

Hi everyone,

The board voted this through on Monday, and I've updated some bits of
documentation accordingly.

 - Tracker issue - https://gitlab.gnome.org/Teams/Board/-/issues/166
 - Committees page - https://wiki.gnome.org/Foundation/Committees/
 - Release Team page -
https://wiki.gnome.org/action/info/ReleasePlanning?action=diff=79=78

The only outstanding action is to update the Foundation trademark
policy with the details of the modulesets we count as "official". I'll
let you know when that's done.

Thanks!

Allan

On Mon, 22 Jun 2020 at 14:35, Michael Catanzaro  wrote:
>
> On Mon, Jun 22, 2020 at 11:28 am, Allan Day  wrote:
> > The board is hoping to vote on this at its meeting later today. I
> > don't think that the vote will have a huge impact on the Release
> > Team, but if anyone has any reservations please let us know ASAP.
>
> Well, besides what I've already mentioned... release team directs core
> technical work. I'm not sure it makes sense for the Board to be
> managing technical work?
>
> > The key thing is that the power to decide official GNOME software
> > resides with the Foundation. So in the arrangement you describe, the
> > release team would need to get authorisation from a staff member
> > whenever they want to add or remove a module from the official
> > modulesets (core-developer-tools, core-os-services, core-shell,
> > core-utilities).
>
> We could have Emmanuele or another Foundation staff member approve such
> changes. I don't think that would be a problem.
>
> Michael
>
>
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Defining GNOME software (finally)

[Allan Day]

Hi Release Team,

The board is hoping to vote on this at its meeting later today. I don't
think that the vote will have a huge impact on the Release Team, but if
anyone has any reservations please let us know ASAP.

Thanks!

Allan

On Mon, 15 Jun 2020 at 11:05, Allan Day  wrote:

> Michael Catanzaro  wrote:
> ...
> > On Mon, Apr 20, 2020 at 1:00 pm, Allan Day  wrote:
> > >   2. We need to bring the definition of that software within the
> > > umbrella of the Foundation
> > >
> > > The basic idea we discussed was to have the Release Team act as a
> > > committee of the board, and maintain some simple documentation about
> > > what GNOME's official software is. At the time it seemed that you were
> > > OK with that, and Matthias added a stub to one of your wiki pages [1].
> >
> > Another option would be to have release team report to a Foundation
> > staff member. This way we'd achieve the goal of bringing release team
> > under Foundation control, but without the overhead and formalism of
> > having to be a committee of the Board.
>
> The key thing is that the power to decide official GNOME software
> resides with the Foundation. So in the arrangement you describe, the
> release team would need to get authorisation from a staff member
> whenever they want to add or remove a module from the official
> modulesets (core-developer-tools, core-os-services, core-shell,
> core-utilities).
>
> I can understand the concern about the bureaucratic overhead with
> being a committee, but I honestly don't think that it's going to be a
> big deal...
>
> Allan
>
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Defining GNOME software (finally)

[Allan Day]

Michael Catanzaro  wrote:
...
> On Mon, Apr 20, 2020 at 1:00 pm, Allan Day  wrote:
> >   2. We need to bring the definition of that software within the
> > umbrella of the Foundation
> >
> > The basic idea we discussed was to have the Release Team act as a
> > committee of the board, and maintain some simple documentation about
> > what GNOME's official software is. At the time it seemed that you were
> > OK with that, and Matthias added a stub to one of your wiki pages [1].
>
> Another option would be to have release team report to a Foundation
> staff member. This way we'd achieve the goal of bringing release team
> under Foundation control, but without the overhead and formalism of
> having to be a committee of the Board.

The key thing is that the power to decide official GNOME software
resides with the Foundation. So in the arrangement you describe, the
release team would need to get authorisation from a staff member
whenever they want to add or remove a module from the official
modulesets (core-developer-tools, core-os-services, core-shell,
core-utilities).

I can understand the concern about the bureaucratic overhead with
being a committee, but I honestly don't think that it's going to be a
big deal...

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Defining GNOME software (finally)

[Allan Day]

Hi everyone,

Allan Day  wrote:
...
> At this point it's probably best for us to share the plan in more
> detail and get more feedback...

I've posted a more complete proposal on Discourse now -
https://discourse.gnome.org/t/official-proposal-how-we-define-gnome-software/3371
. Please feel free to participate in the conversation there.

The board would like to get this wrapped up in the next month, before
the 2020 board elections conclude.

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Defining GNOME software (finally)

[Allan Day]

Michael Catanzaro  wrote:
...
> > We've considered this question a bit more on the board side, and think
> > we can adjust the policy enough to allow some flexibility around the
> > GNOME Gitlab group. I think we would like to see some alignment
> > between the modulesets and the group, but it doesn't have to be
> > absolute and we could have a lazy retirement policy - so a modules
> > that are removed from the modulesets can stick around in the Gitlab
> > group for a good period of time. Does that sound like it could work?
>
> I'm not sure. We have ~400 repositories under GNOME/ but only ~50
> elements under core. So over 85% of our modules in GNOME/ are not in
> core. We could reduce that percentage by including elements from
> core-deps and sdk that are hosted under GNOME/, but there's still going
> to be very wide divergence. For there to be any sort of alignment, we'd
> need to remove the vast majority of software currently under GNOME/.

Yes, that's been taken into account. We're planning to set up a new
group where a lot of those modules will be able to live.

At this point it's probably best for us to share the plan in more
detail and get more feedback...

> The advantages of doing this would be unclear.

The "advantage" is following the legal recommendation we've had,
regarding how we define our software.

Thanks again!

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Defining GNOME software (finally)

[Allan Day]

Allan Day  wrote:
...
> > To make sure we don't have misplaced expectations, please remember that
> > this list cannot be used for deciding what repositories go into the
> > GNOME/ group on GitLab, because probably 90% of the stuff currently
> > there is not core and is therefore excluded from our definition, and
> > also because we add and remove things from core on a semi-regular basis
> > (e.g. we just removed gnome-themes-extra earlier this week). I continue
> > to recommend allowing experienced GNOME developers to create new
> > repositories there as needed.

We've considered this question a bit more on the board side, and think
we can adjust the policy enough to allow some flexibility around the
GNOME Gitlab group. I think we would like to see some alignment
between the modulesets and the group, but it doesn't have to be
absolute and we could have a lazy retirement policy - so a modules
that are removed from the modulesets can stick around in the Gitlab
group for a good period of time. Does that sound like it could work?

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Defining GNOME software (finally)

[Allan Day]

Michael Catanzaro  wrote:
...
> > Any suggestions for who should be chair?
>
> Does it have to be a permanent chair?
>
> With just one formal meeting per year, this doesn't feel necessary to
> me, unless required by the bylaws.

Yes, it's required by the bylaws. In some cases the Foundation might
also reach out to the chair as the contact person for the committee.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Defining GNOME software (finally)

[Allan Day]

Thanks for the reply Michael - very helpful!

Michael Catanzaro  wrote:
...
> So I propose that
> we have the wiki page say that the canonical definition of "what is
> GNOME?" is the list of BuildStream elements listed in
> meta-gnome-core-developer-tools.bst, meta-gnome-core-os-services.bst,
> meta-gnome-core-shell.bst, and meta-gnome-core-utilities.bst.

I was wondering the same thing - this sounds good to me!

> Note it
> intentionally does not include SDK components like GTK or GLib. We
> could potentially expand the definition to include SDK components
> hosted on gitlab.gnome.org, but that would require splitting up sdk.bst.

If those components are relatively stable, could we just list them on
the wiki somewhere? Whatever path offers least resistance is probably
the way to go.

> To make sure we don't have misplaced expectations, please remember that
> this list cannot be used for deciding what repositories go into the
> GNOME/ group on GitLab, because probably 90% of the stuff currently
> there is not core and is therefore excluded from our definition, and
> also because we add and remove things from core on a semi-regular basis
> (e.g. we just removed gnome-themes-extra earlier this week). I continue
> to recommend allowing experienced GNOME developers to create new
> repositories there as needed.

I don't want to comment on the legal aspect of this too much, but we
probably do need a Foundation policy to cover what goes into that
group. At the same time, your point is a good one - we don't want
avoid frequent changes in the Gitlab group membership. The answer to
that is probably to have some exceptions in place in the policy, to
give us a bit of flexibility. We'll figure out the details of that.

> > We'll also need you to confirm that the member list [2] is
> > up to date.
>
> That member list is kept up to date, yes.

Great, thanks!

> > We'd also like to know if you want to keep the Release Team name, or
> > whether you'd prefer to switch to "Release Committee" or "Engineering
> > & Release Committee", or anything else. It's up to you.
>
> I think we're fine with release team.

I thought you'd say that. :)

> > You should also know that becoming a committee will involve some small
> > changes [3]:
> >
> >   - You'll need to have membership changes ratified by the board
> >   - You'll need to have a chair, and minuted meetings

Any suggestions for who should be chair?

> >   - You'll need to keep the board informed about how things are going
>
> Having membership changes ratified seems fairly low cost. We normally
> hold one formal meeting per year, which we take private notes on, so
> the only change there would be to make those minutes formal and public.

There's no requirement for minutes to be public. However, if the
Release Team is a committee it probably make sense for minutes to be
accessible to the Foundation (ie. Board, ED, etc).

> Most of our decision-making occurs on IRC, and not as part of any
> formally organized meeting, and therefore is not minuted.

I don't have much concrete advice regarding when meetings should be
held. My suggestion would be to have them whenever a non-routine
decision has to be made.

Thanks again,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Defining GNOME software (finally)

[Allan Day]

Hi Release Team,

Many many moons ago, we had a call about GNOME trademarks and how the
project defines its official software. The background to this was that
the board has been told that:

  1. We need to clearly state what GNOME's official software is, and
  2. We need to bring the definition of that software within the
umbrella of the Foundation

The basic idea we discussed was to have the Release Team act as a
committee of the board, and maintain some simple documentation about
what GNOME's official software is. At the time it seemed that you were
OK with that, and Matthias added a stub to one of your wiki pages [1].

It's taken us an embarrassingly long time, but we're finally in a
position to make all this happen. I hope that you're still all OK to
go ahead with it!

To move forward, we'll need the wiki page filled out, so we can see
the list of modules which are official GNOME software. Is someone able
to do that? We'll also need you to confirm that the member list [2] is
up to date.

We'd also like to know if you want to keep the Release Team name, or
whether you'd prefer to switch to "Release Committee" or "Engineering
& Release Committee", or anything else. It's up to you.

You should also know that becoming a committee will involve some small
changes [3]:

  - You'll need to have membership changes ratified by the board
  - You'll need to have a chair, and minuted meetings
  - You'll need to keep the board informed about how things are going

We expect all of this to be very light touch, so don't worry about overhead.

We'll be publishing a more detailed plan for the community to give
feedback on. Once that's happened, it'll go to the board for a vote.
Do you have any questions of your own?

Thanks,

Allan
Vice-President, GNOME Foundation Board of Directors
-- 
[1] https://wiki.gnome.org/ReleasePlanning/WhatWeRelease/Criteria
[2] https://wiki.gnome.org/ReleasePlanning/Membership
[3] https://wiki.gnome.org/Foundation/Committees/#Expectations_for_Committees
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break exception for the new lock screen

[Allan Day]

Michael Catanzaro  wrote:
...
> > It is equally not smart to never land the things we've worked on for
> > years just because we put ourselves under the pressure of yet another
> > deadlne.
>
> So far this exception has only one of two required approvals. Do you
> want to give the second approval?

I thought we got the freeze break. We did get it, didn't we?!

Anyway: a brief update - the lock screen work has now been merged
(this is the main reference:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1848 ). A bunch of
testing has already happened, and we've been working through the
issues that have spotted. I'll try and get more people involved in
tested next week. Downstream, Fedora is planning a GNOME 3.36 test day
on Thursday 20th, which will be a good opportunity to test.

I do have a related freeze break request to make of the release team,
but I'll start a new thread for that.

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break exception for the new lock screen

[Allan Day]

An initial version of the test plan can be found here:
https://gitlab.gnome.org/Teams/Design/os-mockups/issues/44

Allan

On Wed, 29 Jan 2020 at 11:38, Allan Day  wrote:
>
> Michael Catanzaro  wrote:
> ...
> > There are many, many, many more like these. Sorry for sending so many
> > mails to this thread, but I just happen to remember this is a
> > particularly fragile portion of the codebase. ...
>
> Thanks, I'll try and include those in the test plan.
>
> I still feel that these issues are better addressed through active,
> coordinated testing and bug fixing, but maybe the best thing to do
> would be to reassess once the MRs are ready and we have the test plan.
> The other thing we'll need is a commitment from the relevant
> developers to fix any issues that come up, before the code freeze.
>
> Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break exception for the new lock screen

[Allan Day]

Michael Catanzaro  wrote:
...
> There are many, many, many more like these. Sorry for sending so many
> mails to this thread, but I just happen to remember this is a
> particularly fragile portion of the codebase. ...

Thanks, I'll try and include those in the test plan.

I still feel that these issues are better addressed through active,
coordinated testing and bug fixing, but maybe the best thing to do
would be to reassess once the MRs are ready and we have the test plan.
The other thing we'll need is a commitment from the relevant
developers to fix any issues that come up, before the code freeze.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break exception for the new lock screen

[Allan Day]

Michael Catanzaro  wrote:
> > Would it be possible to arrange a freeze exception for the lock
> > screen work, so we can plan on having another week to get it merged?
> > We don't expect there to be any new strings and I'm happy to
> > coordinate with docs and marketing.
>
> Certainly possible, but it is wise?

That is the question, and I'm not 100% sure. I certainly share the
concern about landing big features late, but it obviously depends on
what the time buys us. What do we lose if we delay by a week? Do we
expect 3.35.90 to get more widescale testing than master?

My own feeling is that our confidence in the code and our ability to
do rounds of testing and fixing prior to merge are potentially the
most important factors in ensuring quality. Landing a big change right
before UI freeze and walking away is probably worse than landing
something late, but doing plenty of testing and fixing, and having a
plan in place for post-merge testing.

...
> Then again, at least it's not the login screen. Unlock dialog is
> simpler.

The changes affect both unlock and login.

...
> If we do a freeze exception, we'll want to test:
>
>  * Automatic lock after delay
>  * Manual lock with Ctrl+L
>  * Fingerprint unlock
>  * Smartcard or OTP unlock
>  * (What more am I forgetting?)

The testing matrix for login and unlock is potentially large, although
I'm not sure that all these features are touched by the redesign. If
we go ahead I can commit to coming up with a feature list and a test
plan.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break exception for the new lock screen

[Allan Day]

Hi Release Team,

You might be aware that we've had plans for a redesigned lock screen for
some time. Development on this has been proceeding this cycle. Some of it
has landed already, and the other pieces are close to being ready (see my
review here
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922#note_693085
). The main MRs are:

   - https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864 (merged)
   - https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
   - https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922

Georges has been taking the lead on this initiative. He's been away on
vacation for the past couple of weeks; my understanding is that, now he's
back, we should see some rapid progress on MR review and polish work.

I don't want to land the feature before it's ready, but with the bulk of
the work done, and more shell features in the pipe for future releases, it
would be good to get it in if we can.

Would it be possible to arrange a freeze exception for the lock screen
work, so we can plan on having another week to get it merged? We don't
expect there to be any new strings and I'm happy to coordinate with docs
and marketing.

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Release Team presentation at the GNOME Foundation AGM

[Allan Day]

Hi Release Team,

The GNOME Foundation AGM is happening on Saturday, as part of GUADEC, and
it would be great to have a short presentation from the release team. Any
volunteers to do that?

If you want to show slides, please just send me the raw text, preferably no
later than Friday lunchtime.

Thanks,

Allan
-- 
Vice-President & Chair, GNOME Foundation Board of Directors
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-28

[Allan Day]

The branch 'gnome-3-28' was created pointing to:

 5fb4ab8... Update Turkish translation

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Buildstream documentation feedback

[Allan Day]

Tristan Van Berkom  wrote:
...
> I've made changes to both the wiki and the BuildStream user manual
> installing section, and think I have addressed all of your points
> mentioned in this email.

Thanks Tristan! From a cursory look, the wiki page seems much better.
I'll hopefully provide more feedback in the future, or maybe just
suggest some edits.

Best,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Buildstream documentation feedback

[Allan Day]

Hi all,

Today was my first experience using Buildstream, which I did by following
the guide on the GNOME wiki
. I got blocked by
an issue , but I
wanted to provide some notes on my experience using the documentation (see
below).

I'm coming at this from the perspective of someone who regularly builds
GNOME components, but who isn't a developer. I'm used to the old JHBuild
tutorial, which offered a clear set of steps that I found easy to follow.

If I manage to progress further, I'll share more feedback.

Thanks,

Allan
-- 

*Installation*


The page sends me to an installation guide
, which isn't that
easy to follow:

   - I didn't realise that "User installation with pip" was something I had
   to do. As a newcomer, it's an odd title - it isn't clear why it is "user
   installation" or why pip is involved. I would have expected a title like
   "Install BuildStream" or "Installing BuildStream".
   - It doesn't say where to clone the repo.
   - It states "If you are installing as a developer" - it isn't clear what
   this means and I'm not sure whether I'm a developer or not. Am I supposed
   to be any old developer, or of something specific? If I'm not one of these,
   what should I do?


*Configuring buildstream*


The language in this section is quite permissive - it says what the
defaults are, and says what you can do, but this leaves an element of doubt
- I would prefer a tutorial that just says exactly what to do.

It tells me to follow a page on how to configure Buildstream
, which gets
quite technical. I'm basically not interested in this and it felt like a
lot of overhead. I prefer the simple JHBuild tutorial in this regard.

"For developer purposes, we recommend using non strict build planning mode,
which only requires a rebuild of any module which has changed since the
last build." Like before - am I a developer? Why wouldn't I want this? If
it's the best option, why isn't it the default? I'm confused as to the
relevance of this statement.

It talks about adding options to ~/.config/buildstream.conf, but this
doesn't exist.

"Download the GNOME Build Metadata using git" - it doesn't say which
directory I should do this in.

*Building GNOME*


"To build your favorite module" - favorite seems like an odd word to use
here, as if I'm building a particular module for kicks.

It wasn't clear to me that I had to run the build command from the
gnome-build-meta directory, since the command to switch directories was
part of the previous step. This was actually a major stumbling block for me.

The following three sentences mean very little to me, and at times they
sound like technobabble:

   - "Below is an explanation of how to use the tracking feature
   separately. If you have already tracked your sources and just want to
   build, simply issue the same above command without the tracking options:"
   - "BuildStream is deterministic at its heart and as such, it is never
   enough to say "Build the master branch" alone. This is because a symbolic
   branch does not represent a bit-for-bit identical input for your builds. "
   - "In order to get your project into a buildable state, and allow you to
   easily build the latest commit of a given branch, BuildStream
    provides the tracking
   feature to update your project automatically."

These sentences jump into technical details without explaining the basic
concepts, particularly what "tracking" means. It's hard to identify a
logical progression from one to the other.

Partly due to the above, it isn't clear what the "tracking new sources" and
"fetching the latest build metadata" sections are for - it doesn't explain
what they do, when I should use them, or how they're relevant. It says that
the latter is "worth a mention" - this leaves me in some doubt as to
whether it's important or not.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Call with the Board of Directors

[Allan Day]

Allan Day <a...@gnome.org> wrote:
...

> An issue has come up which the Foundation Board of Directors needs to
> speak to you about. It's a legal thing so I can't provide details here, but
> I can fill any of you in privately if you'd like more information.
>
> It would be great if some of you could join a call next week. I've set up
> a Framadata to try and figure out a good time:
>
> https://framadate.org/NcWmTUtL8iYZNXpt
>

Thanks to everyone who has filled in the Framadate. Wednesday at 18:00 UTC
is the only time that everyone can make it, so let's go for that.

If it's acceptable, we can use Bluejeans at
https://bluejeans.com/6361797715/

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Call with the Board of Directors

[Allan Day]

Hi Release Team,

An issue has come up which the Foundation Board of Directors needs to speak
to you about. It's a legal thing so I can't provide details here, but I can
fill any of you in privately if you'd like more information.

It would be great if some of you could join a call next week. I've set up a
Framadata to try and figure out a good time:

https://framadate.org/NcWmTUtL8iYZNXpt

Please fill it in!

The issue isn't super urgent, so if next week doesn't work out we can
organise for another time.

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.26 retrospective

[Allan Day]

Hey Michael,

Thanks for your quick reply. Do bear in mind that these are just ideas; I'm
happy to discard any that don't make sense!

 wrote:
...

> Extend the UI freeze (or create a freeze period for major UI changes) and
>> require that breaks get design approval.
>>
>
> What would extending the freeze accomplish? We already have a long UI
> freeze (five weeks). Wouldn't extending the freeze just make it harder to
> land changes? ...
>
> Why should UI freeze breaks require design approval? I'm not aware of any
> instance of us approving a freeze break that introduced a controversial
> design change. Do you have an example of a freeze break that you wish we
> had not approved? ...
>

The issue I've identified is large changes landing just before the freeze.
Typically these large changes require subsequent smaller changes to make
them release-ready, which often requires close design involvement.

I'm honestly not sure whether we want these big late changes or not (that's
probably a separate discussion). However, one feeling I have is that, if
developers are going to drop a big feature, they ought to be aware of what
improvements are going to be requested by us designers. This is why I
suggested the idea of having a major and a minor UI freeze - the major UI
freeze would start 2/3 before the minor one, would only apply to major
features, and would require design team approval.



> Make it clear at which point UI freeze breaks will no longer be accepted.
>>
>
> Hm, I think it's better to handle these on a case-by-case basis, but in
> general:
>
> * A big new feature that introduces lots of new code is only likely to be
> accepted at the very beginning (the first week or two) of the freeze
> period. This is because features like this are pretty much guaranteed to
> introduce a big crop of new bugs, no matter how carefully-developed.
> * Significant, noticeable UI changes are not likely to be accepted during
> the final week.
>
> But we can and should make exceptions when appropriate. E.g. in the top
> bar transparency case, I thought it made sense to revert back to our
> previous behavior, even though the request came in quite late. Or if a
> feature is long-awaited and very important, maybe it makes sense to let it
> slip in later than usual. The entire process is for seeking an exception
> anyway. We also consider how stable a particular module is...


That's useful information. Maybe it would be useful to advertise the final
week as a "we're really frozen" period, or maybe hard code freeze could be
elaborated to say "freeze break requests are less likely to be accepted
during this period".


> Give marketing a say in whether UI freeze breaks are accepted. (And find
>> someone other than me to take responsibility for this!)
>>
>
> Is this in reference to the nautilus freeze break request? ...
>

Nope.

The other case that went badly this cycle was the transparency freeze break
> request. I think this was a combination of you taking time off at an
> awkward point right after making the request, leaving nobody to ensure it
> was actually implemented, and possible confusion due to Mathias not liking
> the request and due to me forgetting that Andre had given his approval...
>

Regarding that particular case, my feeling is that the issue was not so
much how the freeze break request was handled, but the fact that it
happened so late in the first place. The issue had existed for months; it
shouldn't have been a last minute scramble. I think that a UI review around
the freeze would have drawn attention to the issue earlier and prompted a
more concrete plan for resolving it. I also feel that if it had been
flagged and advertised as a release blocker it would have got more priority
generally.



> Make sure that JHBuild isn't broken, particularly around release time.
>>
>
> Unfortunately some module maintainers do not use JHBuild, and so do not
> notice if their module is broken.
>
...

> We do have a technical solution to this: replace JHBuild with BuildStream.
> ...
>

Yes, integrating JHBuild with our CI setup occurred to me as a possibility
as well. That could be good.

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

3.26 retrospective

[Allan Day]

Hi all,

I personally found 3.26 to be a difficult release and thought that it might
be useful to share some of my experiences, along with some thoughts on how
to improve things for next time around. The issues I encountered:

   1. We had two big features that landed very close to UI freeze, both of
   which required design iteration. This put a lot of stress on me personally
   and meant that other design reviews that I had planned never happened
   (sorry Builder).
  - It's worth noting that if it wasn't for these features, the release
  notes would have been very sparse indeed - from that perspective
I'm happy
  that they did land.
  2. A design change that we had landed early in the cycle, with the
   intention of polishing it later, failed to resolve itself. As the issue
   rolled on it was often unclear what the plan was and what the deadline was
   for rolling back the change that had been made earlier in the cycle.
   3. The release notes were seriously delayed due to 1 and there was
   uncertainty about screenshots because of 2. There were also various issues
   building the release, which made the process of taking screenshots painful
   and time consuming.


I'm sure that some of these issues are down to individuals. However, it
does seem interesting to think about their wider causes, with a view to
improving the release process. In my mind there are a number of these wider
issues, including:

   - Landing complex changes close to UI freeze:
  - This interrupts other planned work, as people have to scramble to
  refine the new feature.
  - If you care about UX quality, it can be stressful!
  - It makes a bit of a mockery of the UI freeze, since features are
  dropped with the expectation that the freeze can be freely
broken in order
  to refine them. This in turn creates uncertainty about whether we can
  expect freeze breaks to be accepted.
  - Unrealistic expectations for what we can provide with each release,
   in terms of quality and feature set.
   - Lack of awareness of, or at least uncertainty around, what our UX
   release blockers are.
   - Uncertainty as to how late UI changes can be made.
   - Lack of general involvement in the QA phase of our releases - while
   some of us are sweating over what we're going to put into the hands of
   users, a lot of people are working on other things.
   - Outside of the maintainers, there isn't much awareness of the release
   schedule and the various deadlines that comprise it. This is particularly
   the case for non-developers.
   - Lack of general awareness of the current state of master.


Below are some ideas for things we could possibly do to improve the
situation. I'm sure that some of these aren't good and that you all will
have better ones!

   - Extend the UI freeze (or create a freeze period for major UI changes)
   and require that breaks get design approval.
   - Either let go of the idea that each release will have an interesting
   feature set or figure out a way to plan releases so that they're
   interesting *and* high quality.
   - Make it clear at which point UI freeze breaks will no longer be
   accepted.
   - Give marketing a say in whether UI freeze breaks are accepted. (And
   find someone other than me to take responsibility for this!)
   - Include a UI review exercise as part of the release schedule, around
   the UI freeze. Tie this in with identifying release blockers.
   - Do more "product management" - track more issues for each release,
   publicise them more.
   - Ensure that there are bootable VM images that can be used to review
   the state of master.
   - Get people using nightly apps. Could Software have a way to bulk
   install nightly Flatpaks? Could we have some kind of QA programme that
   encourages people to use nightlies and report issues, particularly in the
   run up to a release?
   - Publicise the release schedule in a way that reaches non-developer
   audiences: have a public calendar that anyone can subscribe to (and perhaps
   allow other teams to add their own deadlines), make announcements on social
   media, etc...
   - Make sure that JHBuild isn't broken, particularly around release time.

Thoughts? Opinions? I'd be happy to invest some time in this.
Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

UI/hardcode freeze break request for GNOME Shell

[Allan Day]

Hi all,

This is a break request that changes some visual styling in GNOME shell.
The code changes are deliberately minimal. However, the visual change is
noticeable.

The design team recognise that it is late in the cycle but we'd be unhappy
putting the release out in its current state.

The bug containing the patch:
https://bugzilla.gnome.org/show_bug.cgi?id=787446

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-26

[Allan Day]

The branch 'gnome-3-26' was created pointing to:

 ab83e0a... Update French translation

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-24

[Allan Day]

The branch 'gnome-3-24' was created pointing to:

 89bf4d5... Update Turkish translation

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-22

[Allan Day]

The branch 'gnome-3-22' was created pointing to:

 1021c57... Updated Polish translation

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-20

[Allan Day]

The branch 'gnome-3-20' was created.

Summary of new commits:

  9c53ba0... prepare for 3.20
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Moduleset review

[Allan Day]

It would be great to sync GNOME continuous with the revamped modulesets:
I've recently been using continuous to test 3.19.x, and there are quite a
few core apps that are missing (as well as some not so interesting apps
that are included).

Allan

On Thu, Feb 4, 2016 at 10:32 AM Allan Day <allanp...@gmail.com> wrote:

> PM, Michael Catanzaro <mcatanz...@gnome.org> wrote:
> ...
> > I've just landed this. It got delayed a bit as I found I had broken a
> > few things.
>
> Thanks for taking it forward, Michael!
>
> Allan
>
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Moduleset review

[Allan Day]

PM, Michael Catanzaro  wrote:
...
> I've just landed this. It got delayed a bit as I found I had broken a
> few things.

Thanks for taking it forward, Michael!

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Moduleset review

[Allan Day]

Michael Catanzaro  wrote:
> On Mon, 2016-01-11 at 18:37 +, Javier Jardón wrote:
>> This has been merged now
>
> Thanks for working on this, Javier; I think our modulesets are much
> better now. I posted a follow-up patch for the metamodules here:

And thanks to you for doing a much more thorough job than I did, Michael!

Having well organised modulesets that reflect the current state of the
project is a good thing in itself. That said, when I originally looked
at this, I had wider goals, and it is possibly worthwhile to revisit
what these are, and what other steps might be required to achieve
them.

 * Help the GNOME project focus, and help contributors to understand
the layout of the project, by providing a common organisation which
reflects our priorities and direction. (This implies that contributors
will be exposed to the moduleset definitions, through the organisation
of git.gnome.org, Bugzilla, etc. This goal won't be reached if no one
sees the modulesets.
 * Make decisions around modules (and specifically apps) more
transparent, and provide some kind of accountability for those changes
through the release team. So if we were to switch from one core app to
another, it would be clear how and why that decision had been made.
 * Promote exposure of the experience as designed, and enable testing
of this experience. So, for example, testers could download live
images featuring the core default experience, as we want it to be.
 * Communicate to distros what our intended default install looks like.

Perhaps there are other goals worth considering here?

> Apps in Workstation, but not gnome-core:

This list looks good to me, with the following questions/comments:

> bijiben

While I do believe that there needs to be a notes app in the core
experience, I'm concerned that bijiben isn't of sufficient quality
right now.

> evolution

Not sure this should be in core to be honest: it's a heavy enterprise
thing, which might makes sense in some contexts more than others.

> gnome-boxes

I like the idea of having Boxes in the default install, although maybe
that has size implications for install media? I think this could go
either way, to be honest.

> vinagre

Isn't this superceded by Boxes?

> Apps in gnome-core, but not Workstation:
>
> empathy
> epiphany
> gnome-logs
>
> I think Empathy should be removed from core unless a new maintainer
> surfaces. Epiphany is under active development. We should probably add
> Logs downstream.

Makes sense.

> Now, the design team has a page with designs for GNOME core apps
> here:
>
> https://wiki.gnome.org/Design/Apps

It's worth bearing in mind that this list is something of an
idealisation: it's future orientated rather than rooted in the here
and now.

> It is much more expansive than what we have currently. Ignoring apps
> that don't exist yet, it includes the following which we do not have in
> core:
>
> gnome-documents (and gnome-books)
> gnome-photos
> gnome-music
> gnome-clocks
> gnome-maps
> gnome-weather
> gnome-calendar
> bijiben
> gnome-dictionary
>
> It also includes Mail and Chat, but the designs are so far from Evolution and 
> Empathy that it's quite up for debate whether or not we should include those 
> apps until replacements exist. I'm curious to know your opinions on this (and 
> Allan's in particular).

I agree that Empathy is a long way from what we want, and shouldn't be included.

My view is that Evolution - as designed - is a specialised app for
people in corporate environments, who have a need for a complete
Outlook replacement. It obviously overlaps with Mail, Calendar,
Contacts and Notes. I wouldn't recommend installing it by default.

> The design team list omits:
>
> evince
> eog
> gnome-font-viewer
>
> I would like to implement the proposal from the design team. Some specific 
> thoughts:
>
>  * It's not lost on me that we just removed Dictionary from core. I thought 
> this would be uncontroversial; Allan, was this a mistake? Should we put it 
> back?

Having a dictionary is nice, particularly if it has a search provider.
But it's also not essential, so if our dictionary isn't up to scratch
it wouldn't be the end of the world not to have it in the default
install.

>  * I will consult Richard to see if Color Manager is still needed by 
> gnome-control-center. If so, we need to move it to core. It has a 
> NotShowIn=GNOME desktop file, so this should be uncontroversial, but it is 
> showing up in GNOME Software as an app, which needs to be fixed.

My understanding is that it's a control center requirement, indeed.

>  * I will consult with the gedit developers regarding de-branding the
> desktop file, as I think gedit should be in core. I do notice that
> gedit is conspicuously missing from the design page, but I think it is
> too important to omit.

gedit's role has always been rather fuzzy. It's a basic editor, but it
can also be expanded into something much more complex. It's treated as
part of the default 

Re: Test days

[Allan Day]

For what it's worth, I have 22 February and 7 March in my calendar as
test days. I'll probably informally ask people if they want to join
me, at the least.

Allan

On Thu, Nov 26, 2015 at 4:36 PM, Sriram Ramkrishna <s...@ramkrishna.me> wrote:
>
>
> On Thu, Nov 26, 2015 at 8:30 AM Allan Day <a...@gnome.org> wrote:
>>
>> Javier Jardón <jjar...@gnome.org> wrote:
>> ...
>> >>> [1] https://bugzilla.gnome.org/show_bug.cgi?id=750726
>> >
>> > Seems Andrea from sysadmin team is going to take a look this weekend
>>
>> Fantastic news!
>>
>
> That is pretty awesome.  Looking forward to seeing image composing working
> reliably again.
>
>
>>
>> Looking at the calendar, I'm wondering about doing two explicit rounds
>> of testing: one a week after UI freeze is scheduled, and one about a
>> fortnight prior to the release itself. Does that sound about right?
>
>
> Sounds good to me.  I'd like to get some kind of extension testing framework
> in place by then. This could just be as simple as getting people to test it
> as part of test days, or maybe something automated using the images.  I've
> added Vadim to see if he has any thoughts on this.
>
> sri
>
>>
>> Allan
>> ___
>> release-team@gnome.org
>> https://mail.gnome.org/mailman/listinfo/release-team
>> Release-team lurker? Do NOT participate in discussions.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Test days

[Allan Day]

Javier Jardón  wrote:
...
> Great idea, but I think first we should fix the generation of ISO
> images from continuous [1] so the people can test the latest. Not sure
> what is blocking that fix

Or perhaps setting the test days would help to put pressure on these
issues? Is there anyone other than Colin that we can poke about that
bug?

Allan

> [1] https://bugzilla.gnome.org/show_bug.cgi?id=750726
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Test days

[Allan Day]

Javier Jardón  wrote:
...
>>> [1] https://bugzilla.gnome.org/show_bug.cgi?id=750726
>
> Seems Andrea from sysadmin team is going to take a look this weekend

Fantastic news!

Looking at the calendar, I'm wondering about doing two explicit rounds
of testing: one a week after UI freeze is scheduled, and one about a
fortnight prior to the release itself. Does that sound about right?

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Signing apps on Google Play store

[Allan Day]

Frederic Peters  wrote:
...
> I still have no idea on technical details, and I'm still reluctant on
> releasing an .apk we would receive, no question asked...

I'm in favour of us releasing this app under a GNOME account. However,
I also agree that we should decide what kind of quality controls would
be required, and how the usual GNOME processes would apply. One
question I have is whether the usual module requirements would be made
for an Android application, for instance.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Google Play account

[Allan Day]

Zeeshan Ali (Khattak) zeesha...@gnome.org wrote:
...
 Release team is usually pretty busy and thin on resources so I'm not
 sure if they could take more work/responsibility on their shoulders,
 but I'll ask (adding to CC).

Dealing with these kinds of issues is why we have a Release Team.

 A good starting point would be to
 create a wiki page for the app
...
 That could be easily arranged, Ankit could you please take care of
 that?

Thanks!

...
 I guess I'm missing something here, but what would be the motivation
 for moving to freedesktop.org?

 Cause geoclue is there and this is more a part of geoclue than GNOME,
 even though currently GNOME is the only desktop that will benefit from
 it.

 I'm not so sure about this. GNOME seems far better equipped to
 maintain and release user facing software than Freedesktop.

 Of course but IMHO that is not relevant unless we want release team to
 create infra to build (and upload binaries to Play store). ...

I still don't get your logic here. If you want the GNOME community to
draw your artwork, help with design, do testing, write translations,
do advertising, etc, then why not host on GNOME infrastructure? Or are
you not interested in any of those things?

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-18

[Allan Day]

The branch 'gnome-3-18' was created pointing to:

 fd2841a... Updated Turkish translation

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.18 topics: application revival

[Allan Day]

Hi all,

Just a quick message to let you know that I haven't forgotten about
this discussion. Since we last talked, I've been working with Jakub
and the relevant maintainers to draw up roadmaps for each of the
priority apps. I'm now doing some publicity work around these, through
a series of blog posts [1, 2]. The Engagement Team are also helping
out with publicity.

It might be interesting to think about other activities we can
organise around this.

Allan

[1] https://blogs.gnome.org/aday/2015/06/16/plans-for-gnomes-apps/
[2] https://blogs.gnome.org/aday/2015/06/24/notes-future-plans/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Empathy/Telepathy Future

[Allan Day]

Hi all,

We've recently discussed this in a different thread, but I thought
that it probably deserves one of its own.

In short: Empathy and Telepathy haven't got development time for quite
a while, and the Empathy UX isn't great. At the same time, popular
chat protocols are mostly closed nowadays, meaning that having a
built-in chat client potentially isn't as important as it used to be.

Possible ways to deal with the situation:

1. Advertise for new contributors/maintainers to either revamp the
existing Empathy UI, or create a new Telepathy-based chat client.

2. Based on the outcome of 1, reach out to other Telepathy users
(primarily on the KDE side, I'm guessing), and see if we can organise
more development.

3. Remove the existing Empathy integration in GNOME, particularly on
the online accounts side, but also possibly the shell. This would
effectively turn Empathy into a third-party application.

4. Recommend to distros that Empathy shouldn't be installed by
default, and change the logic of Software so that it isn't mandatory.

5. Tell users that Empathy is no longer recommended (could be done
through Software, or through Empathy itself, or something else).

These options could be combined in different ways...

My personal view is that the GNOME community ought to be given the
opportunity to pursue option 1 if it wants to, and that the Release
Team could make an announcement to that effect. At the same time, I
don't feel that chat is all that high a priority, and would probably
encourage people to work on other things (Music, Notes, Photos or
Videos in particular).

If option 1 doesn't work out, we can discuss 3, 4 and 5.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Let's not do feature proposals for 3.17.x

[Allan Day]

I've put the new page under ReleasePlanning, and filled in some
features that are in the works for 3.18:

https://wiki.gnome.org/ReleasePlanning/FeaturePlans

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Minor UI freeze break - bug 745095

[Allan Day]

Hi all,

With the notification redesign landing so late, it had some rough
edges in certain places. I'd like to land a small CSS patch to take
care of some of those. Bug 745095 [1] has the details, including
before and after screenshots [2].

Thanks,

Allan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=745095
[2] https://bug745095.bugzilla-attachments.gnome.org/attachment.cgi?id=297958
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-16

[Allan Day]

The branch 'gnome-3-16' was created pointing to:

 b55779b... Initial Hungarian translation from 3-12 branch

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Initial List of 3.16 Target Bugs

[Allan Day]

Andre Klapper ak...@gmx.net wrote:
 Just commenting on term confusion; no other content.
...
 I've been using gnome-version to mark project level priorities.

 I think/hope you mean GNOME Target.
 Because GNOME version does not have a 3.15/3.16 entry yet (and is not
 meant for planning but desribes in which version the bug happened).

  We
 *could* encourage maintainers to use gnome-target to track their own
 priorities...

 That is what the Target Milestone field is meant for, plus maintainers
 can add entries themselves to that dropdown.

Very sorry for the confusion. You're exactly right Andre.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Initial List of 3.16 Target Bugs

[Allan Day]

Andre Klapper ak...@gmx.net wrote:
 On Sun, 2014-11-23 at 22:11 +, Javier Jardón wrote:
 But I think it would be good to ping the maintainers to suggest them
 to put the GNOME target field in the bugs we think are important, so
 we know which ones are willing to work on the problem for the next
 release

 Javier: I'm sorry, but I don't get it.

 That's exactly what Allan did (thanks, Allan!):
 Putting the GNOME target field in the bugs we think are important.

I've been using gnome-version to mark project level priorities. We
*could* encourage maintainers to use gnome-target to track their own
priorities...

 But if I get you right you ask for some way to get feedback from
 maintainers if they really plan to work on those marked tickets?

It might be good to do this - I've already had some conversations with
maintainers where they agree that a target bug is important, but don't
have the time to work on it themselves. Perhaps we could use a keyword
for this (help-wanted?), or just flag those bugs when we publicise
them on the mailing list.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: New release processes

[Allan Day]

Javier Jardón jjar...@gnome.org wrote:
...
  * Identify priority bugs at the start of the cycle. Allow people to
 suggest their own bugs.

 Yeah, lets allow maintainer to set the gnome-target in their modules.
 I think we already allow this.

I think they can set target-milestone (not gnome-target). That could
work though - we can invite them to set their own targets, and then
pick from those to include them in gnome-target.

We should include own bugs too. I know I have, *ahem*, one or two bugs
I'd like to put on the list.

 Then we can have a meeting and build list between all of us.
 Should we arrange the meeting time already? what about at some point
 just after the 3.14.1 release?
...

Sounds great to me.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: New release processes

[Allan Day]

Matthias Clasen matthias.cla...@gmail.com wrote:
...
 Right, so here is what I suggest we could do to avoid a repeat of the
 feature proposal fiasko from last cycle:

 Instead of clamoring for feature proposals on desktop-devel-list, we,
 as the release team could go out and suggest waht we think would be
 great features to work on for the next cycle. Could be stuff like:
...

I like the idea of something that is proactive and lightweight... What
would the purpose of feature proposals be, under this arrangement?
Would they still be the way that people propose new apps or libraries?

  * Identify priority bugs at the start of the cycle. Allow people to
 suggest their own bugs.
  * Advertise the initial bug list.
  * Track them over the course of the cycle, and communicate our progress.
...
 If the RT is interested in trying this, I'd be happy to propose the
 idea on d-d-l and see if I can get some buy-in.

 I am, very much. Thanks for keeping up the pressure, Allan!

Great, I'll get that moving.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: cleaning up categories

[Allan Day]

Frederic Peters fpet...@gnome.org wrote:
...
 At GUADEC we discussed cleaning the various categories we have for our
 modules, to make things more understandable and to share things
 between our various services.
...
 Where do we go from here?

Sorry for not replying to this sooner, Fred. I was a bit confused
about it, for some reason. :)

 Notes and suggestions: (not a plan)

  - we want a flat list. (but does that mean merging all four jhbuild
core subcategories in a single core, or dispatching things in
various parts?)

My suggestion was to have a common schema across our infrastructure:

1. Core (currently Core Shell and Core Dependencies from gnome-core-suites)
2. Core apps (currently Core Utilities from gnome-core-suites)
3. Apps (gnome-apps)
4. World (gnome-world)

I personally feel that separate modulesets for 1  2 would be
clearest, although I don't have much insight into the technical
underpinnings.

  - damned lies  bugzilla lists should be created from the doap files.

This would be fantastic. Do we have bug reports for these changes?

  - ditto for developer.gnome.org  help.gnome.org.

  - admin: it exists in the doap file schema but it's not used anymore
(it was pessulus  sabayon)

Seems fine to remove it for now, as far as I can see.

  - backends (damned lies) / shell (jhbuild): sounds like absolutely
core things, it will technically break if a module is removed

To me the key thing to differentiate is the core system (ie. OS
components) from applications. Within the core OS, it might be helpful
to categorise modules for navigation purposes, but that seems
secondary.

...
  - development tools: special purpose apps (anjuta, devhelp, gitg,
nemiver...) should be considered apps.

Right, they're just apps.

 Then there is zenity, what
about it?

Seems like it's part of the OS - ie. not an app.

...
  - devel platform / extra devel platform: we need to decide on a
precise set, we also need to decide on the presence of bindings
here.

That seems like something that should happen in concert with Alex's
bundling/runtime work.

...
 Comments?

Like I said, my personal priority is to have a common set of
high-level categories - core, core apps, apps. I'd probably opt to try
and get that in place rather than trying to solve every detail at
once.

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

To Do List

[Allan Day]

Hi all,

I was struggling to figure out what was outstanding after the BoF at
GUADEC, so I converted the notes into a task list on the wiki:

https://wiki.gnome.org/ReleasePlanning/ToDo

I know there's a risk of this going stale. It's only really of use if
there's going to be RT meetings where the list can be reviewed.

It should probably be merged into:

https://wiki.gnome.org/ReleasePlanning/Tasks

I'll take care of that, unless someone tells me otherwise.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: To Do List

[Allan Day]

Allan Day allanp...@gmail.com wrote:
...
 It should probably be merged into:

 https://wiki.gnome.org/ReleasePlanning/Tasks
...

I just did it. Feel free to revert though.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: New release processes

[Allan Day]

Allan Day a...@gnome.org wrote:
...
 Here's my attempt to summarise the processes that we discussed in
 yesterday's meeting. I've had to fill in some gaps and make some
 guesses. It's very much a draft.
...

I was hoping that we would push forward with these new processes for
3.16. Some of them will need further discussion - it would be great if
that could happen soon.

One thing I'm particularly keen to get started with soon is the roadmap part.

...
 Roadmap process

  * During the planning phase, the Release Team prompts maintainers to
 review their bugs and mark priority issues for the user experience.
 This is done using the target-milestone field in Bugzilla.
  * At the end of the planning phase, the Release Team:
  - Reviews the list of target-milestone bugs and marks issues that are
 important at a project-level. This is done with the gnome-target
 Bugzilla field.
  - Add their own bugs to the gnome-target list. This is done with
 input from the Design Team.
  - Discusses the list of gnome-target bugs with maintainers, to get a
 sense of whether the maintainer can commit to fixing them during the
 current cycle.
  - Publishes the list of gnome-target bugs on d-d-l, putting emphasis
 on bugs which need help from outside the module.
  * At regular intervals during the release cycle:
  - New bugs can be proposed for the gnome-target. [How would this happen?]
  - The Release Team reviews the in-progress gnome-target list.
  - Sends an update to d-d-l.
...

What I described here is maybe a little over-engineered. The main
thing I want to happen for 3.16 is:

 * Identify priority bugs at the start of the cycle. Allow people to
suggest their own bugs.
 * Advertise the initial bug list.
 * Track them over the course of the cycle, and communicate our progress.

This would be someone like UX Papercuts or Every Detail Matters, but
for the whole GNOME UX, and managed by the Release Team (I'd be doing
the work though).

If the RT is interested in trying this, I'd be happy to propose the
idea on d-d-l and see if I can get some buy-in.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-14

[Allan Day]

The branch 'gnome-3-14' was created pointing to:

 407c2c0... OPW-Updated Greek translation

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: moduleset review

[Allan Day]

 Javier Jardón jjar...@gnome.org wrote:
...
 https://wiki.gnome.org/AllanDay/Modulesets

 Thanks for working on this!

 Only wanted to point that gnome-suites-core-deps contain the dependencies for
 core, not only non-GNOME dependencies (GTK+ and GLib are there for example).
 Maybe we can be more strict and move things over, and leave -core-deps
 for external deps only (that we need to build, for dependencies we
 expect are available in the system we use -sysdeps)

That might be best - good to have a clear criteria for which modules
go into that moduleset.

...

 I wonder if it would be clearer to change Core Utilities to Core
 Apps, or even to split them out into a new moduleset
 (gnome-core-apps).

 I'd be ok with both changes
 I think is clearer ro have a matching between meta modules and the
 file, as we have with meta-gnome-apps-tested and gnome-apps now.
 So we can have:

 gnome-core to build meta-gnome-core
 gnome-core-apps to build a new renamed meta-gnome-core-apps
 gnome-apps to build meta-gnome-apps-tested

 Then gnome-core-deps and gnome-sysdeps for external deps

Sounds good.

 Also, while we're on the subject, the word suites
 in gnome-suites-core and gnome-suites-core-deps always confused
 the hell out of me. It makes it sound like each moduleset contains
 different suites that you can install...

 same here, I guess we can rename to gnome-core and gnome-core-deps if
 the rest agree

Great.

Thanks!

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: moduleset review

[Allan Day]

Allan Day allanp...@gmail.com wrote:
 2)  Drop gnome-system-log from core-apps, replace with gnome-logs
 3) Move gnome-dictionary, gucharmap, totem, eog, empathy, evince to apps
 4) Move file-roller, gnome-clocks, gnome-documents, gnome-photos,
 gnome-weather to core-apps

 Before move stuff, Id like to define the difference between core-apps
 and apps, so we have a criteria to do the change,
 if not we are going to be in the same situation we are now, were
 everything is a bit fuzzy
 Also, can a app be a core-app at some point? If yes, What would be the
 process to do that? Ot they are 2 completely different things?

 Makes sense to me. Also, it would be good to communicate these changes
 to the rest of the project before making widescale changes.

 I'd be happy to draft some documentation for the modulesets.
...

I've started writing some documentation on the various modulesets. It
can be found here:

https://wiki.gnome.org/AllanDay/Modulesets

I'll try and elaborate it in the next day or two. Once we're happy
with it, it would be good to move it under ReleasePlanning (it might
be a good idea to merge it with ReleasePlanning/WhatWeRelease).

I wonder if it would be clearer to change Core Utilities to Core
Apps, or even to split them out into a new moduleset
(gnome-core-apps). Also, while we're on the subject, the word suites
in gnome-suites-core and gnome-suites-core-deps always confused
the hell out of me. It makes it sound like each moduleset contains
different suites that you can install...

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: moduleset review

[Allan Day]

Javier Jardón jjar...@gnome.org wrote:
...
 2)  Drop gnome-system-log from core-apps, replace with gnome-logs
 3) Move gnome-dictionary, gucharmap, totem, eog, empathy, evince to apps
 4) Move file-roller, gnome-clocks, gnome-documents, gnome-photos,
 gnome-weather to core-apps

 Before move stuff, Id like to define the difference between core-apps
 and apps, so we have a criteria to do the change,
 if not we are going to be in the same situation we are now, were
 everything is a bit fuzzy
 Also, can a app be a core-app at some point? If yes, What would be the
 process to do that? Ot they are 2 completely different things?

Makes sense to me. Also, it would be good to communicate these changes
to the rest of the project before making widescale changes.

I'd be happy to draft some documentation for the modulesets.

By the way, these are the modules I'd move from gnome-apps to core-apps:

bijiben
gnome-weather
accerciser
gnome-documents
gnome-maps
cheese
file-roller
gedit
gnome-clocks
gnome-photos
gnome-software
orca
seahorse

 5) Move orca, gnome-initial-setup to core

 Yep, makes sense
...

Not sure. While I'd like Orca to behave more like a part of the
system, it does currently look and behave like an app...

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

New release processes

[Allan Day]

Hi all,

Here's my attempt to summarise the processes that we discussed in
yesterday's meeting. I've had to fill in some gaps and make some
guesses. It's very much a draft.

One issue that we didn't agree on during the BoF - I've moved the
governance (ie. when the Release Team has a formalised opportunity to
say no) part of the process from feature proposes to moduleset
changes. This is mainly because I don't feel that the Release Team is
in a position to require a feature proposal in order for that feature
to land.

Looking forward to hearing your thoughts on this.

Allan

---

Planning process

 * Major/interesting changes that are planned by modules are listed on
the wiki for each release, in the same way as with the current feature
process.
 * Plans can include any initiative, whether it affects user
experience or is purely technical in nature. Plans do not have to be
specific to the current release cycle - they are a statement of intent
and desire, rather than a concrete commitment to deliver a feature
within a specific time period.
 * Maintainers are encouraged to add their plans at the beginning of
each cycle (within a 2 week planning phase). The Release Team sends
reminders to d-d-l for this.
 * The Release Team works with maintainers of priority modules during
this period, in order to ensure that their plans are documented. It
can also add any plans that it knows about on behalf of maintainers.
 * Plans do not need to be approved by the Release Team, and there is
no acceptance period. However, the Release Team can intervene if
advertised plans are problematic or controversial.
 * At the end of the planning phase, the Release Team reviews the
plans that have been added to the wiki. At this point, the Release
Team can intervene if necessary. The Release Team then sends a mail to
d-d-l which summarises plans for the coming cycle.
 * Plans can be added to the wiki after the planning phase, at any
point during the release cycle. When this happens, it is the
responsibility of the plan proposer to notify d-d-l by email.

Roadmap process

 * During the planning phase, the Release Team prompts maintainers to
review their bugs and mark priority issues for the user experience.
This is done using the target-milestone field in Bugzilla.
 * At the end of the planning phase, the Release Team:
 - Reviews the list of target-milestone bugs and marks issues that are
important at a project-level. This is done with the gnome-target
Bugzilla field.
 - Add their own bugs to the gnome-target list. This is done with
input from the Design Team.
 - Discusses the list of gnome-target bugs with maintainers, to get a
sense of whether the maintainer can commit to fixing them during the
current cycle.
 - Publishes the list of gnome-target bugs on d-d-l, putting emphasis
on bugs which need help from outside the module.
 * At regular intervals during the release cycle:
 - New bugs can be proposed for the gnome-target. [How would this happen?]
 - The Release Team reviews the in-progress gnome-target list.
 - Sends an update to d-d-l.

Moduleset change process

 * Only the Release Team can change the JHBuild moduleset definitions.
 * If the Release Team updates a moduleset, they send a notification to d-d-l.
 * If a developer or maintainer wants to add/remove a dependency or
module, they must send a request to the Release Team (via d-d-l?)
 * New modules must adhere to documented standards (this would be an
updated version of the old module inclusion guidelines). This will
include adherence to the new version of the HIG.

Post-release meetings

 * One week after a release, the Release Team organises a debrief
meeting with representatives of the GNOME project teams (documentaton,
design, accessibility, QA, internationalisation, engagement).
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: status icon freeze break request

[Allan Day]

Any update on this? I'm going to be taking screenshots for the release
notes later, and it would be good to know whether the icon updates
will make it into the final release.

Allan

On Mon, Mar 17, 2014 at 2:40 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 On Mon, Mar 17, 2014 at 10:32 AM, Jakub Steiner jim...@gmail.com wrote:
 Turns out the patch didn't include the exported wireless-offline
 state. I've remedied it now. So to clear up possible confusion, the
 last after state is to include the x as well. The one depicted is
 for network-wireless-signal-none.


 Thanks for the comparison screenshots. I don't see a problem with
 this, so +1 for the release team. But the more important approval for
 this would be from the docs team.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: status icon freeze break request

[Allan Day]

Matthias Clasen matthias.cla...@gmail.com wrote:
 Will this affect screenshots taken for the release notes ? I guess we
 don't usually take those while offline.

I don't think it will. Having a decision on this freeze break will
possibly help us decide what to take shots of though.

Jakub Steiner jim...@gmail.com wrote:
 I'd like to request a freeze break for unifying offline status for all
 sorts of device types that creeped up on us.

 https://bugzilla.gnome.org/show_bug.cgi?id=726321

To provide some background - this is a small change to some of the
network status icons. As far as docs are concerned, it's probably only
relevant to screenshots.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: status icon freeze break request

[Allan Day]

Ekaterina Gerasimova kittykat3...@gmail.com wrote:
...
 Screenshots are the most labour intensive part of docs to update, both
 for the docs team and translators. If it affects the wireless network
 icon, then I would prefer for the change to wait until after the
 release as we're running out of time now.

As previously stated, I couldn't find any screenshots that include
these icons. I'd be surprised if there are any.

Also, I take a lot of the screenshots for the release notes - yell if
there are any screenshots needed by docs; I might be able to provide
them.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: status icon freeze break request

[Allan Day]

Andre Klapper ak...@gmx.net wrote:
...
 Clueless as I haven't seen a before/after screenshot, but we're not
 talking about stuff like
 https://git.gnome.org/browse/gnome-user-docs/plain/gnome-help/C/figures/network-error-symbolic.svg?h=master
 ?

These icons are for the offline/disconnected states for mobile
broadband, wired and wireless networks. The main places these are
exposed are in the control center's network panel, the shell top bar,
and the shell system status menu. A before and after image of the
icons is attached (it's a bit hard to reproduce all the states in
order to produce screenshots of them in use).

Allan
attachment: network-offline.png___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-12

[Allan Day]

The branch 'gnome-3-12' was created pointing to:

 65a51ae... Added Greek translation

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Intent to ask for freeze break

[Allan Day]

Shaun McCance sha...@gnome.org wrote:
...
 This is just a heads-up that, if I can manage to get everything done
 this weekend, I intend to ask for a freeze break to implement Allan's
 designs for Yelp:
...
 Not happening. Too much left to do, too unstable, and too many design
 questions still unanswered. We'll just do this the right way and wait
 for 3.14.

Thanks for trying Shaun! It was a valiant effort.

I'd be really happy to help out next cycle.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze Break Request: Session Menu Heading

[Allan Day]

Hi everyone,

We've got a small cosmetic change that we'd like to make. The session
menu in the login screen was changed in 3.10. Unfortunately, the
Session heading lost its styling, so it looks like a regular menu
item.

The change simply involves making Session bold. Here's a screenshot
from the bug [1]:

https://bug707072.bugzilla-attachments.gnome.org/attachment.cgi?id=253544

Thanks,

Allan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=707072
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze Break Request: Session Menu Heading

[Allan Day]

On Thu, Aug 29, 2013 at 8:59 PM, Javier Jardón jjar...@gnome.org wrote:
 On 29 August 2013 20:43, Allan Day allanp...@gmail.com wrote:
 Hi everyone,

 We've got a small cosmetic change that we'd like to make. The session
 menu in the login screen was changed in 3.10. Unfortunately, the
 Session heading lost its styling, so it looks like a regular menu
 item.

 The change simply involves making Session bold. Here's a screenshot
 from the bug [1]:

 https://bug707072.bugzilla-attachments.gnome.org/attachment.cgi?id=253544

 Im not a designer, but should the Session entry exist at all?
 Anyway, Its a small change, so 1/2 for release team

Ha, yes. I think you're right. Let's say we'll just remove it. I'm
assuming we still have your +1. :)

Sorry docs people, I think I misspelled the address of the docs list
in my original mail.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze Break Request: Session Menu Heading

[Allan Day]

Matthias Clasen matthias.cla...@gmail.com wrote:
 Im not a designer, but should the Session entry exist at all?
 Anyway, Its a small change, so 1/2 for release team

 Ha, yes. I think you're right. Let's say we'll just remove it. I'm
 assuming we still have your +1. :)


 +1 to putting the lost styling back. Not sure sure about removing the
 heading altogether - will the meaning of the menuitems still be
 obvious if we remove it ?

Given the placement of the gear icon and the content of the menu, I
think so - it's clearly a login option. Session doesn't add much in
the way of useful information anyway.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for bug 694796

[Allan Day]

Michael Hill mdhil...@gmail.com wrote:
 +1 from docs team.

 Mike

Thanks Mike! I've pushed the fix.

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for bug 694796

[Allan Day]

Hi all,

We've introduced new iBus character popups this cycle - these are the
menus that let you choose different characters when using an input
method. We got some early feedback that we'd like to address with
these, basically by changing how the popups are themed. This is
tracked in bug 694796 [1].

The change would be entirely visual and won't functionally affect how
the feature is used.

Allan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=694796
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[release-notes] Created branch gnome-3-8

[Allan Day]

The branch 'gnome-3-8' was created pointing to:

 9a8ae8a... Revert Add Esperanto translation

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.8 Release Notes Writing

[Allan Day]

Andre Klapper ak...@gmx.net wrote:
 [Not CC'ing marketing-list@ yet]

 It's time to start preparing the GNOME 3.8 release notes.

 I won't have time to help this year, but maybe I can help out with some
 smaller sections.

 Had a quick chat with Allan Day (CC'ed) here at DevConf, and sounds like
 Allan would be interested again.

Thanks for the push Andre.

I've started the process [1, 2] and will see if I can get some extra help.

Allan

[1] https://live.gnome.org/ThreePointSeven/ReleaseNotes
[2] 
https://mail.gnome.org/archives/desktop-devel-list/2013-February/msg00106.html
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Fallback mode is going away - what now ?

[Allan Day]

Matthias Clasen matthias.cla...@gmail.com wrote:
 to be fair, I'd envision this as a completely separate session that
 you need to install and select, similar to what Ubuntu does —
 especially if we want to call it GNOME Classic.

Agreed.

 I don't think a separate session will work very well for this - for
 one thing, setting this up will require a number of settings to be
 tweaked (e.g. the one for the minimize button), and alternative
 sessions don't have the right infrastructure for that.

A separate user session would be the best user experience, IMO.

 The session
 chooser on the login screen is not the best designed part of the login
 experience either.

That's a non-argument. We can improve it.

The Tweak Tool is *completely* the wrong place for this. In what way
is completely changing the shell a tweak? How does it make sense to
be able to completely change the experience using a setting that is
included in a non-core application, and which could later be removed?
What kind of experience will you get when the shell transitions to
classic mode right in front of the user's eyes?

The Tweak Tool shouldn't have anything to do with extensions. They are
something that you install and run as a part of the system, not
something to be tweaked via settings.

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: live image

[Allan Day]

Hey Ray,

Ray Strode halfl...@gmail.com wrote:
...
 I put together a live image with a jhbuild built in it here:

 http://ftp.acc.umu.se/pub/gnome/misc/testing/GNOME-3.5.1-LiveUSB.iso
...
 It's a little hacked together, at the moment.  I'd like to get the
 process I used more refined and potentially automated so we can do
 testing more easily and regularly through the development cycle.
...

Automated builds would be fantastic; I'm sure they would improve the
quality of our releases. Thanks for working on this.

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.4 Release Notes

[Allan Day]

On Fri, Mar 9, 2012 at 3:53 PM, Vinicius Depizzol vdepiz...@gmail.com wrote:
 On Thu, Mar 8, 2012 at 18:53, Sriram Ramkrishna s...@ramkrishna.me wrote:

 My main objection would be translation.  One of the problems is that I would
 like to see our content/news/release notes translated so that we can have
 greater coverage.  I feel that english makes us somewhat limited.

 We can have WordPress content translated and integrated with
 damned-lies with the plugin I developed during the last Summer of
 Code[1]. I'm in contact with Claude Paroz (damned-lies maintainer) and
 Andrea Veri (sysadmin) to get a testing version of it running ASAP.

 [1] http://git.gnome.org/browse/gnome-web-wppo

We're pretty much out of time for this. We should really have a draft
of the release notes finished already. I'm busy working on them using
the existing infrastructure.

It will be great to have gnome.org translatable anyway, of course, and
I really hope that we can use the site for the 3.6 release notes.

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Shell Modal Dialog Tweakage

[Allan Day]

On Mon, Mar 12, 2012 at 2:21 PM, Shaun McCance sha...@gnome.org wrote:
 On Mon, 2012-03-12 at 10:40 +, Allan Day wrote:
 The first is the apparent lack of consensus. I was following what I
 understood to be good practice, and even went out if my way to be
 considerate towards the docs team. It's frustrating to then be told
 that I'm breaking the rules. I largely agree with Matthias's last
 message, but I also want some clarity.

 You went out of your way to send an email? What's frustrating is when
 people act like they're doing me some huge favor by following rules
 that have been in place, in varying forms, since before I joined GNOME
 nine years ago.

Sure, an email certainly isn't a massive effort. The point is that I
was acting in accordance with the guidelines as they were explained to
me.

 It's patronizing and borderline insulting.

I'm sorry that you feel that way.

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Shell Modal Dialog Tweakage

[Allan Day]

On Sun, Mar 11, 2012 at 1:02 AM, Shaun McCance sha...@gnome.org wrote:
 Replying to two in one, to save electrons.

 On Sat, 2012-03-10 at 13:03 -0500, Matthias Clasen wrote:
 On Sat, Mar 10, 2012 at 9:49 AM, Allan Day allanp...@gmail.com wrote:
 
  Now, if we want to define and write down an exact list of things we do
  not require approval for (but still require notification), I'm OK with
  that.
 
  I don't recall suggesting that you construct an exact list of things
  we do not require approval for. All I'm saying is that a single
  sentence isn't a lot to go on. A few more details would be helpful.

 Allan:

 What I'm saying is that all the extra verbiage is what we would need
 to have exceptions. The single sentence right now is very clear. It
 doesn't mention exceptions, therefore there's no reason to assume any.

  It's clear that many people don't understand the rules the way you do.

 And that's why I engage developers when I think they're not following
 the release process. I'm happy to have a more public discussion about
 this. Our release process is always evolving, and I've always taken
 part in those discussions.

 I think it is important to not lose sight of the goal here.

 The freeze is not there so we in the release team or the documentation
 guys can feel empowered.  The goal is to ensure that we end up with a
 high-quality release and docs that match the actual product well
 enough to not confuse users.

 Matthias:

 I think one of the big benefits of the freezes is that they act as
 a deterrent to making lots of small changes.

 One small discrepancy isn't a big deal. As you mentioned earlier,
 very few people will likely even notice a discrepancy in the docs
 with this particular change. (By the same token, though, very few
 people will notice the change at all, and that makes it much less
 urgent to get it into this release.)

I wouldn't have pushed this change if I didn't think it was urgent. As
you say below, details matter.

 But if we don't discourage changes after the freezes, then it won't
 be one small discrepancy. It will be 20 or 50 or 100. And then our
 help and marketing materials and other stuff look unprofessional.
 Yes, I care if our help looks professional. I care that it gives
 the impression that it's current, because we're fighting a user
 perception problem born out of a decade of useless and outdated
 manuals. Details matter.

 Allan only sent a notification because another developer suggested
 he should. And he apparently made some font size changes without
 notification. That suggests to me that people are not deterred at
 all from making post-freeze changes, and that potentially lots of
 small changes are being made that I don't know about. It adds up.

Well yes, one patch changed some text from 10.5pt to 11pt. I think
there was another one that changed a text style from 9pt to 9pt bold
(all part of a much larger theme cleanup, I might add). These are
exactly the kinds of changes that shouldn't require freeze breaks, in
my opinion.

 That suggests to me that people are not deterred at
 all from making post-freeze changes, and that potentially lots of
 small changes are being made that I don't know about. It adds up.

Personally speaking, there are two issues here.

The first is the apparent lack of consensus. I was following what I
understood to be good practice, and even went out if my way to be
considerate towards the docs team. It's frustrating to then be told
that I'm breaking the rules. I largely agree with Matthias's last
message, but I also want some clarity.

The second issue is what the policy should actually be. This is really
up to the release and docs teams, but my personal opinion is that
minor cosmetic changes that don't impact on the docs shouldn't require
a break request. We're busy enough without having to jump through
extraneous bureaucratic hoops.

Allan
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Shell Modal Dialog Tweakage

[Allan Day]

On Sat, Mar 10, 2012 at 11:13 AM, Andre Klapper ak...@gmx.net wrote:
 On Fri, 2012-03-09 at 18:36 +, Allan Day wrote:
 And yet there is also an understanding that minor cosmetic changes
 don't need a UI freeze exception.

 https://live.gnome.org/ThreePointThree#Schedule says No UI changes may
 be made without approval from the release-team and notification to
 gnome-doc-list@.
 I don't see any major or minor mentioned so I disagree with that
 interpretation, plus subjects/individuals would have to define minor
 and would likely differ on it with others.
 = Just ask first, we don't bite (I think). :)

If you expect any UI change, no matter how small or insignificant, to
require freeze break approval, then I suggest that the release team
communicates that fact to the rest of the development community.

I'd also add that one sentence is not an adequate amount of guidance
for this process.

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Shell Modal Dialog Tweakage

[Allan Day]

On Sat, Mar 10, 2012 at 2:35 PM, Shaun McCance sha...@gnome.org wrote:
 I'd also add that one sentence is not an adequate amount of guidance
 for this process.

 The sentence looks clear to me. It doesn't say maybe or only major
 or at your discretion. It says No UI changes.

 No UI changes may be made without approval from the release-team and
 notification to gnome-doc-list@

 Compare to:

 no string changes may be made without confirmation from the l10n team
 (gnome-i18n@) and notification to both the release team and the GDP
 (gnome-doc-list@)

 We don't add commas to string without approval, just because it's only
 a small string change. So where's the confusion? What's the difference
 between these two rules?

 Now, if we want to define and write down an exact list of things we do
 not require approval for (but still require notification), I'm OK with
 that.

I don't recall suggesting that you construct an exact list of things
we do not require approval for. All I'm saying is that a single
sentence isn't a lot to go on. A few more details would be helpful.

It's clear that many people don't understand the rules the way you do.

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Shell Modal Dialog Tweakage

[Allan Day]

On Fri, Mar 9, 2012 at 3:48 PM, Andre Klapper ak...@gmx.net wrote:
 Hi Allan,

 On Thu, 2012-03-08 at 18:50 +, Allan Day wrote:
 I've just pushed a minor change to the GNOME Shell theme [1]. This is
 a small visual change [2, 3], and it doesn't
 affect anything functionally. It does change the look of the dialogs
 very slightly though. It was suggested that I you a heads up since
 we're in UI freeze.

 What blocked you to contact the Documentation team and the release team
 first to ask for a UI freeze exception, instead of just committing?

 andre

It's a minor style change that doesn't affect how the dialogs are
used, so it wasn't clear to me that it did require a UI freeze break.
I checked with the module maintainer and he advised me to commit and
mail the docs list.

Allan
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Shell Modal Dialog Tweakage

[Allan Day]

On Fri, Mar 9, 2012 at 4:55 PM, Shaun McCance sha...@gnome.org wrote:
 On Fri, 2012-03-09 at 11:33 -0500, Matthias Clasen wrote:
 On Fri, Mar 9, 2012 at 10:48 AM, Andre Klapper ak...@gmx.net wrote:
  Hi Allan,
 
  On Thu, 2012-03-08 at 18:50 +, Allan Day wrote:
  I've just pushed a minor change to the GNOME Shell theme [1]. This is
  a small visual change [2, 3], and it doesn't
  affect anything functionally. It does change the look of the dialogs
  very slightly though. It was suggested that I you a heads up since
  we're in UI freeze.
 
  What blocked you to contact the Documentation team and the release team
  first to ask for a UI freeze exception, instead of just committing?

 If Allan hadn't sent this headsup, would you have noticed the change ?
 In other words, is there really such great value in ensuring that
 documentation screenshots are pixel-perfect ? I can see the point if
 things get actually rearranged, or strings changed, or new
 functionality added, but here we are talking about shifting some
 whitespace around - everybody who looks at the before and after
 screenshots will recognize them as the same dialog...

 I don't think anybody would have blocked this change. (I certainly
 wouldn't have.) But I don't like the idea of qualifying our freeze
 with unless you don't think you need to. We entrust the release
 team to make those decisions.

And yet there is also an understanding that minor cosmetic changes
don't need a UI freeze exception. I recently pushed a patch that
changed some font sizes by a point or two. I presume that's not
something I need a UI freeze exception for, for example.

If you think this change went too far, then fine - next time I'll go
through the procedure. However, it seems a bit over the top to go
through that for this type of change.

Allan
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.4 Release Notes

[Allan Day]

On Wed, Mar 7, 2012 at 10:25 PM, Sriram Ramkrishna s...@ramkrishna.me wrote:


 On Wed, Mar 7, 2012 at 1:08 PM, Andre Klapper ak...@gmx.net wrote:


 I was thinking of switching from Docbook to Mallard for 3.6 (I didn't
 have time to prepare this for 3.4 already).
 The advantages of GNOME 3 page style are unclear to me currently,

Advantages of moving over to using Wordpress for the release notes
(that I can think of):

 1. The notes will be on gnome.org rather than under
library.gnome.org/misc (why are the notes for our new release in a
'library'? why are they 'miscellaneous'?)

 2. Avoid the bookishness of the format (sub-headings everywhere,
boxes of links interrupting the flow of the document), which is rather
stilted.

 3. Allow embedding of richer media, such as lightboxes, image
galleries and videos.

 4. Allow flexible design, facilitating a more stylish and attractive layout.

 5. Allow division of the notes into separate pages, rather than being
a single *huge* page.

 however I would first have to know what markup language this move would
 imply,

Wordpress reduces the need for markup. The only markup you need is
html for formatting and embedding media, plus for bits of fancier page
layout.

 plus if anybody would be actually willing to prepare this move.

Actually writing the notes and doing the markup would be less work
than with Docbook or Mallard, so in that respect we'd save time and
effort. However, we would need a bit of extra help on the web
development side if we wanted to make the notes look really nice.

 I'm interested in this as well.  As Shaun noted about translations I would
 like to see this translated in as many languages as possible.

 We'll need to start on this soon.

Most of the pieces are in place to make gnome.org translatable using
the standard GNOME infrastructure. We just need to hook it up to damn
lies [1]. I've spoken to Vinicius and he's confident that we can have
it ready in time to get the release notes translated.

Allan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=671647
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.4 Release Notes

[Allan Day]

Thanks for kicking this off, Andre! I'll be sure to chip in where I
can. My last blog post [1] might be useful, too.

Now, a question. We typically keep the release notes secret until the
release itself. At least one member of the press has told me that this
makes it quite difficult for him to cover GNOME releases, since there
is little information about the release until it is actually out.

Is there a way we can disclose what will be in the release prior to
release day itself? Maybe the release notes could be made public with
the release candidate, for example? It would be really useful to know
what other projects do in this regard.

One other thing that we've spoken about is moving away from the
library/documentation format for the release notes. Hosting them
directly on gnome.org would give us a lot more freedom in terms of how
we present the notes (so they would look more like the GNOME 3 page
[2], for example).

Allan

[1] http://afaikblog.wordpress.com/2012/02/28/looking-forward-to-gnome-3-4/

[2] http://www.gnome.org/gnome-3/

On Tue, Mar 6, 2012 at 12:31 PM, Andre Klapper ak...@gmx.net wrote:
 I've committed an initial stub for the 3.4 release notes:
 http://git.gnome.org/browse/release-notes/commit/?h=gnome-3-4id=87991dfb2c52704db6481ab3c3d78d7dc73d22e7

 The required steps are (hopefully) documented on
 https://live.gnome.org/AndreKlapper/WritingReleaseNotes

 @fpeters: Could you please set up
 http://library.gnome.org/misc/release-notes/3.4/ with password
 protection?

 andre
 --
 mailto:ak...@gmx.net | failed
 http://blogs.gnome.org/aklapper

 --
 marketing-list mailing list
 marketing-l...@gnome.org
 http://mail.gnome.org/mailman/listinfo/marketing-list
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Power settings ui freeze break request

[Allan Day]

On Fri, Sep 2, 2011 at 6:00 PM, Bastien Nocera had...@hadess.net wrote:
 On Fri, 2011-09-02 at 18:51 +0200, Frederic Peters wrote:
 Matthias Clasen wrote:

  On Thu, Sep 1, 2011 at 10:57 AM, Shaun McCance sha...@gnome.org wrote:
   On Thu, 2011-09-01 at 15:41 +0100, Allan Day wrote:
   On Thu, Sep 1, 2011 at 2:01 PM, Shaun McCance sha...@gnome.org wrote:
On Thu, 2011-09-01 at 12:12 +0100, Allan Day wrote:
   ...
The new design has been reviewed by several members of the design
team. I've checked the user documentation and, from what I can tell,
these changes will not have much impact there.
   
The basic UI reshuffling will affect about a dozen pages. Maybe
a few more from the removal of what to do when the power and
sleep buttons are pressed, but that change already went in on
master (after the announcement period, without an announcement).
   ...
  
   These are the changes the break request is for:
  
   http://bugzilla-attachments.gnome.org/attachment.cgi?id=195390

These changes hit the 3.2 branch yesterday.

There was a string change to the mockup that I posted: 'On AC power'
became 'When plugged in'. The 'Never' combobox entry was also changed
to 'Don't suspend', although that wasn't specified in the design I
circulated.

I hope that's OK.

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Power settings ui freeze break request

[Allan Day]

On Thu, Sep 1, 2011 at 2:01 PM, Shaun McCance sha...@gnome.org wrote:
 On Thu, 2011-09-01 at 12:12 +0100, Allan Day wrote:
...
 The new design has been reviewed by several members of the design
 team. I've checked the user documentation and, from what I can tell,
 these changes will not have much impact there.

 The basic UI reshuffling will affect about a dozen pages. Maybe
 a few more from the removal of what to do when the power and
 sleep buttons are pressed, but that change already went in on
 master (after the announcement period, without an announcement).
...

These are the changes the break request is for:

http://bugzilla-attachments.gnome.org/attachment.cgi?id=195390

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: 3.2 Release Notes: Featured Apps

[Allan Day]

On Wed, Aug 31, 2011 at 8:49 PM, Jason D. Clinton m...@jasonclinton.com wrote:
 On Wed, Aug 31, 2011 at 14:30, Allan Day allanp...@gmail.com wrote:
 For reference, the existing featured apps can be found on gnome.org
 [1]. Asking whether the applications on that page are the best
 non-core GNOME applications out there today might be a good way to
 proceed. Are there any obvious candidates that have been missed? Are
 there any new applications that are worthy of mention?

 The intended purpose of the Featured Apps status is to highlight high
 quality but not to say that they are the best. The goal is to promote
 the whole ecosystem.

OK; high quality examples from our wondrous ecosystem then. :)

Some possible candidates: VLC, Scribus, Transmission. Any other ideas?

(It's still not clear to me how featured applications are going to fit
into the release notes, btw...)

Allan
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.