ope / US / APAC rotation as it lets us reach users
locally once per year (for the US) and once every 2 years (for Europe /
APAC). But there is definitely room for evolution there as well.
--
Thierry Carrez (ttx)
__
OpenSt
doesn't feel right anymore.
We can bikeshed on the name for the new event later :)
Comments, thoughts ?
--
Thierry Carrez (ttx)
events.pdf
Description: Adobe PDF document
__
OpenStack Development Mailing List (not for usage
can along with its lock API also provide a token for each
lock that can be used to interact with a storage layer (and that token
can checked by the storage layer to avoid storage layer corruption).
+1
--
Thierry C
s in logs and others
might find it funny if a previously-translated string suddenly becomes
untranslated.
Now there can be exceptions, where the value of changing the string
outweighs the value of not changing it (like, the error message itself
was wrong)... but it should really be an e
, while the TC
dinner ... well, maybe Austin is the time to show some leadership
on that? ;)
Well, Tokyo was the time to show some leadership on that -- there was no
"TC dinner" there :)
--
Thierry C
having
the TC step out of the way of getting things done. Decisions from that
group can easily be appealed to the TC if a conflict arises. The only
issue is the consistency between the two repositories, but I think it's
manageable.
TL;DR: +1
--
side you have corner cases like Poppy where the
"proprietary service" it plugs into is difficult to replicate since it's
as much physical infrastructure than software.
--
Thierry Carrez (ttx)
__
OpenSta
hon-searchlightclient
python-solumclient
solum
solum-dashboard
solum-infra-guestagent
For projects following the independent model:
=
You don't need to do anything since the project does not follow the
cycle and therefore will not be part of th
ut the community, we would end up with the same
problem we are trying to solve. Most of the cross-project folks that
would end up organizing the event would be too busy organizing the event
to be able to fully participate in it.
--
t just needs to happen earlier.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/
So please stand by while we finalize that: I think you will like the end
result.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?
Dean Troyer wrote:
On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez mailto:thie...@openstack.org>> wrote:
My personal take on that is that we can draw a line in the sand for
what is acceptable as an official project in the upstream OpenStack
open source effort. It should have a
ability come into account ? There will
always be some subjectivity there, but I think it's a good place to start.
Comments ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
Prompted by the discussion on DLM I thought she should at least document
somewhere that OpenStack services can assume the presence of a database
(oslo.db), a message queue (oslo.messaging) and soon a DLM. And then
expand f
I think solution 2 is the best. To avoid too much contention, that can
easily be delegated to the API WG, and escalated to the TC for
resolution only in case of conflict between projects (or between a
project and the API WG).
--
Thierry Carrez (ttx)
!
The Summit events staff regularly emits new discount codes to account
for recent new contributors (or new project teams being recognized as
official). Your friend should automatically receive a code in a future
batch.
Regards,
--
Thierry Carrez (ttx
there. The docs
team is an horizontal project team, which means it intersects with
multiple vertical teams. This is different from a cross-project effort,
which involves multiple vertical and horizontal team temporarily
collaborating together on a specific endeavor.
that list (which is the goal after all). A proper column layout would
be preferable...
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
ittee.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thierry Carrez wrote:
Christian Berendt wrote:
FEBRUARY 1 IS THE DEADLINE TO SUBMIT A TALK (11:59PM PST)
I tried to edit a submitted talk and got the following message:
Call for speaker closed!
Also I have the following note in my interface:
Warning! You reached presentations submissions
looks like it closed the CFP one day too early. I reported the
issue to the site maintainers, but it will take a few hours before it
gets fixed...
FWIW I expect the deadline to be pushed back to tomorrow as a result.
--
Thierry Carrez (ttx
#x27;s there
to serve us and so we shouldn't be slaves to it.
+1, sounds like the best option at this stage.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
the same problem space ? I suspect this is
more low-level ? Is there some potential for convergence between the two
projects ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions
to
being more prescriptive about them.
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openst
6.
Cheers!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Flavio Percoco wrote:
On 21/01/16 11:55 +0100, Thierry Carrez wrote:
As you said, projects can already decide to restrict feature
development in a given cycle, so this is nothing new. We only need to
communicate more aggressively that it is perfectly fine (and even
encouraged) to define the
tion
cycle" or another limited-feature-addition period.
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:uns
distribution. You should
now follow links from:
http://docs.openstack.org/releases/
That will ultimately link to https://tarballs.openstack.org.
We are working on moving all that to https://releases.openstack.org and
implement artifact GPG signing as well.
--
Thierry Carrez (ttx
Kyle Mestery wrote:
One question I have is, what should the version for projects be? For
example, for Neutron, M1 was set to 8.0.0.0b1. Should the M2 Neutron
milestone be 8.0.0.0c1? Or 8.0.0.0b2?
Good question! It should be X.0.0.0b2, so 8.0.0.0b2 for Neutron.
Cheers!
--
Thierry Carrez (ttx
y, then it can definitely apply to become "an OpenStack
project". It's still a bit far away from that state though... the first
step if you want to go in that direction would be to host it under
OpenStack dev infrastruct
an exception to this series:
http://lists.openstack.org/pipermail/openstack-dev/2016-January/084161.html
Cheers,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
Ihar Hrachyshka wrote:
+1. CVE fixes obviously should be granted an exception.
+1
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
Michael Still wrote:
I think Tony would be a valuable addition to the team.
I think Tony would be a valuable addition to /any/ team.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions
l their slots booked.
One possible solution here would be to check if the meetings currently
scheduled on your ideal slots are actually still using the spot, as
there are a non-trivial amount of dead meetings around. You can ping me
on IRC so that we do a quick check.
Regards,
--
-speakers/
[2] https://etherpad.openstack.org/p/austin-upstream-dev-track-ideas
Cheers!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
not be used for more vertical team
meetings.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists
releases/liberty is the current stable release.
I don't think we have that anywhere in machine-readable form currently.
I would support having a reference YAML file in openstack/releases that
would be used to generate doc/source/index.rst (and could also be read
by other tools).
--
Th
cycle-with-milestones) to be included in the final Mitaka
release, please propose an openstack/governance change to do that
(change in the reference/projects.yaml file) ASAP !
I know Magnum plans to do so but hasn't yet.
--
Thierry C
mittee/others to know the contribution of
one project, especially useful for the TC when the project ask for TC approve.
I totally agree. Stackalytics contains data for non-OpenStack projects
anyway (see under "complementary"), so I think it's fine to list
unofficial projects under "
ports could be accepted. Sounds like a good topic to add to the
stable team meeting agenda if you want a more definitive answer to that
question.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage ques
/pypi/tabulate#table-format ) than prettytable
and the api is pretty much the same (or nearly).
So that's another way to handle this (just to move off prettytable
entirely).
This sounds like a reasonable alternative...
--
Thierry C
ly
to the Technical Committee for recognition.
Only TC-recognized projects are allowed to use the OpenStack name in
conjunction with their project name, so calling them "openstack others"
projects is misleading.
--
Alexandre Levine wrote:
The ec2-api project is in gating and totally functional. We'll apply for
it to become OpenStack project very shortly. Next week in fact.
Great to hear! Thanks Alex.
--
Thierry Carrez
increased
risk of introducing a delta between the implementation and the mock. If
the main benefit is that it's used in other Rackspace projects for
testing (like Ben said), I'm not sure that makes a compelling argumen
Thierry Carrez wrote:
[...]
All the projects you are mentioning are hosted on the OpenStack
infrastructure (in the space formally known as Stackforge) but are not
official OpenStack projects.
I meant "formerly" :)
--
Thierry C
Stack
infrastructure (in the space formally known as Stackforge) but are not
official OpenStack projects.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
https://review.openstack.org/#/c/263368/
Could we have a quick status update on the ec2-api project ? It has not
applied to become an OpenStack project yet...
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (no
Thierry Carrez wrote:
Bi-weekly meetings are going to be affected by the new year, as two odd
ISO week numbers are following each other.
Week 52: Dec 21 - Jan 27
Week 53: Dec 28 - Jan 3
Week 1: Jan 4 - Jan 10
https://en.wikipedia.org/wiki/ISO_week_date
That means on the week of Jan 4th we&#x
tion
date. This bug will cause the generated iCal to be off (showing
biweekly-odd meetings on that week) until it's regenerated on week 1.
Sorry for the confusion this will (without doubt) create.
I'm still wishing everyone a happy $END_OF_YE
w and I'll
> get an agenda put together. Otherwise I'll plan for the first meeting in
> early January.
I can attend next week, but it's probably better to maximize the
attendance for the first team meeting(s) so
ike, "backport it directly
to the local copy"). I couldn't quickly find a thread reference though.
Maybe wait for Doug or dims to be around and chime in.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
batched inside the weekly -dev digest from thingee (and
crosspost that one to -announce). Even if the audience is "users" I
think getting a weekly digest from the -dev ML can't hurt ?
> * Do SDK releases fit on -announce?
I guess t
ated dates the the schedule.
NB: you already can and should !
Please propose changes to:
http://git.openstack.org/cgit/openstack/releases/tree/doc/source/schedules/mitaka.rst
--
Thierry Carrez (ttx)
__
OpenStack Development
ave. From all such YAML files you would generate a
global .ics calendar (containing all cycles, to avoid forcing people to
resubscribe every cycle).
The current RST is not that great to edit anyway (you have to get the
table layout right), so having all the deadlines in a YAML file would
act
overlap so significantly the Neutron
leadership can vouch for them being done by "the neutron project team",
they should stay in. If the subteams do not overlap, or follow different
development practices, or have indepe
Matt Riedemann wrote:
> We've had a few high priority regression fixes in stable/liberty [1][2]
> so I think it's time to do a release.
> [...]
You probably mean 12.0.1 ?
--
Thierry Carrez (ttx)
__
Op
Matt Riedemann wrote:
> We've had a few high priority regression fixes in stable/liberty [1][2]
> so I think it's time to do a release.
> [...]
You probably mean 12.0.1 ?
--
Thierry Carrez (ttx)
__
Op
Thierry Carrez wrote:
> Thierry Carrez wrote:
>> The nomination deadline is passed, we have two candidates!
>>
>> I'll be setting up the election shortly (with Jeremy's help to generate
>> election rolls).
>
> OK, the election just started. Recent contr
Julien Danjou wrote:
> On Tue, Dec 08 2015, Thierry Carrez wrote:
>
>> Quite a few projects were using the option to fix-release directly
>> already and behavior there doesn't change.
>
> That makes sense, indeed.
>
>> Could you detail what your workfl
Thierry Carrez wrote:
> Julien Danjou wrote:
>> On Mon, Dec 07 2015, Doug Hellmann wrote:
>>> As mentioned previously [1], as part of deprecating our use of Launchpad
>>> for tracking completed work we have changed the default behavior so that
>>> when a
hat bugs are left lying in FixCommitted
state forever since nobody goes and manually set them to FixReleased to
close them:
https://bugs.launchpad.net/openstack/+bugs?field.status%3Alist=FIXCOMMITTED
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
ase we issued before reno was rolled out in every project.
> for other projects it would be
> super nice if release team could bulk add link
> http://docs.openstack.org/releases/releases/liberty.html#liberty-$PROJECT
> in all Liberty series summaries in Launchpad.
Agree
named... but this seems to be delayed.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack
s and bugs
fixed for those pre-reno releases.
Deleting those milestones would lose useful user information for no
gain: you can't use them anymore (since they are closed) so they are
unlikely to confuse anyone ?
--
Thierry Carrez (ttx)
_
should be something like 'baremetal-XXX' or 'baremetal
>> XXX'. Is it correct? Which separator is preferred?
>
> FWIW we have 3 different projects under the telemetry umbrella and they
> do not share any prefix.
My take is to rename ironic-inspector to clous
The next development milestone, mitaka-2, is scheduled for January
19-21, 2016.
Cheers!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
clear list of all development
deadlines in a given development cycle, making it easier to keep track
of everything.
Please help by adding your own project information to this page!
Cheers,
--
Thierry Carrez (ttx
> I imported the ICS file, but the only event in it is a "Neutron
> Distributed Virtual Router Meeting"...?
You must have clicked the wrong one. I just downloaded:
http://eavesdrop.openstack.org/calendars/networking-midonet.ics
htt
Armando M. wrote:
> On 2 December 2015 at 01:16, Thierry Carrez <mailto:thie...@openstack.org>> wrote:
>> Armando M. wrote:
>> >> One solution is, like you mentioned, to make some (or all) of them
>> >> full-fledged project teams. Be aw
Thierry Carrez wrote:
> The nomination deadline is passed, we have two candidates!
>
> I'll be setting up the election shortly (with Jeremy's help to generate
> election rolls).
OK, the election just started. Recent contributors to a stable branch
(over the past year) s
escribe projects that have a
Rally profile). We'd likely need to bikeshed on names and colors, but I
think the idea of describing project relationships using tags is a
well-accepted one.
--
Thierry Carrez (ttx)
_
this means the TC would judge
those new project teams individually and might reject them if we feel
the requirements are not met. We might want to clarify what happens then.
Thanks for raising this thread!
--
Thierry Carrez (ttx)
_
The nomination deadline is passed, we have two candidates!
I'll be setting up the election shortly (with Jeremy's help to generate
election rolls).
Cheers,
--
Thierry Carrez (ttx)
__
OpenStack Development Ma
2].
> [...]
I like it. That sounds like a great way to ensure cross-project efforts
don't fall into the cracks. The same horizontal group (chapter? guild?)
could also ultimately end up tracking cross-project cycle goals.
--
Thierry Carrez (ttx)
pushing a
patch are varied, so a bit more hand-holding is valuable. It also makes
for a better inter-personal experience to interact with a human on IRC
vs. interacting with step-by-step instructions posted on a bug.
So low-hanging-fruit tagging + available mentors sounds like a powerful
Sean Dague wrote:
> Right, so to me this seems that privsep just needs a NULL mode, and
> we're done. If oslo.rootrwap was never supported on windows, I don't
> think privsep really needs to be in a real way.
+1
--
;s not tested, it's broken"
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
re per-project, so ideally you would find a pilot
project (or a few pilot projects) ready to play with a
"I-added-instructions-for-first-timers-to-follow" type tag. If those are
successful, we could then encourage every other project to adopt it too...
--
Thierry Carrez (ttx)
___
days in the cycle, spread out so
> as not to distract too much from dev work.
Sounds worthy of a #success !
http://lists.openstack.org/pipermail/openstack-dev/2015-October/076552.html
--
Thierry Carrez (ttx)
__
OpenSt
everyone already in -alt needs to move.
I think it's a one-time cost to solve the confusion over the long run,
rather than keep the -alt non-standard construct forever. People have to
join new meeting channels regularly, it's not as if you'd "lose" people
in the process.
--
T
stopping using Launchpad, not stopping tracking
> things correctly.
We already weren't tracking things correctly. The new change tracking
system (which is based on git commits rather than whatever Launchpad
thinks has been merged) is correct.
> On 11/24/2015 05:26 PM, Thierry Carrez wro
aunchpad,
while the plan is to focus Launchpad usage solely on task tracking :)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.op
initially merged), rather than by
assuming some areas of the code are now a specific organization's fault
(and therefore segmenting your code maintenance duties).
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing
g #openstack-meeting-2 and
> making
> it redirect to #openstack-meeting-alt?
I'd rather standardize and rename -alt to -2 (i.e. redirect -alt to -2
on IRC, and bulk-change all meetings YAML from -alt to -2).
--
Thierry Carrez
this last change, we complete
the separation and can use Launchpad purely as a task tracker. So
project teams can use milestone targeting to plan work (or not) however
they see fit, without impacting release management.
--
Thierry Carrez (ttx)
ability fixes
> when they have the resources dedicated to it].
>
> Thanks for your time reading this.
+1
There are so many ways to abuse strict rules that it's better to have a
loose, trust-by-default policy and a strong history of fi
ay, Nov 30. Elections will then be
held if needed the week after.
Thanks!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
still
create stable/mitaka branches if they want to. I expect Gnocchi to stay
release:independent because it has no need to track the common cycle,
and maintain its own set of stable branches.
Hoping this clarifies,
--
Thierry Carrez (ttx)
__
Thierry Carrez wrote:
> [...]
> I'm mostly away this week at a conference, but now that we have a list
> of names, we should set up a meeting early next week to further discuss
> team goals and initial leadership.
We'll be holding a preliminary meeting today (Monday) at 1
elease months
after the x release is done and shipped.
I'll elaborate on that with a more complete proposal on Monday.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
U
nce those grenade jobs themselves needs?
>
> So all in all, is the cost doing above too much to get indicator that tells
> us when Juno --> Kilo upgrade is not doable anymore?
Let's wait a bit for this discussion for th
tly affecting users", so not urgent news
for "users wanting to keep up with upstream news" and can wait to be
mentioned in the weekly digest.
The community weekly newsletter is not "upstream news directly affecting
users" but more of a general digest on openstack news &
anches" (they just won't
be "stable/liberty" but something like "stable/2.0". What the tag should
be describing is if the stable branches follow the common stable policy,
or if they have their own rules.
So we plan to discontinue the "has-stable-branches"
e inconvenience of having these renamed to
> stable/x if that becomes the right thing to do)
Sure, that shouldn't block you.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Uns
morph into a more complete
chapter about IRC in the project team guide:
http://docs.openstack.org/project-team-guide/
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (n
in the release team on how to model those
projects that want to track a given release cycle but will lag. Should
they be independent, cycle-with-intermediary, or a new thing ?
* have an internal discussion in the to-be-created stable branch
maintenance team about using a tag (instead of reserving
ixers is essential.
I'm mostly away this week at a conference, but now that we have a list
of names, we should set up a meeting early next week to further discuss
team goals and initial leadership.
--
Thierry Carrez (ttx)
iar with stable branch
> policies. If there are no objections from the current stable-maint-core
> and keystone-stable-maint teams, then I'd like to add him.
+1, he already knows and applies stable policy !
--
Thierry Carrez (ttx)
___
to it due to its history.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/m
ssion
if anyone wants to.
NB: Mike and Anne are still coming up with a final proposal on how to
reform cross-project meetings and cross-project spec workflow. I suspect
they will post when both are back from vacation (probably next week).
--
Thie
801 - 900 of 2055 matches
Mail list logo
