Future of the cedar branch
Ehsan Akhgari
tl;dr: I can't maintain cedar forever alone, we need to figure out what
we want to do with it.
I started the cedar branch at the beginning of the development period
for Firefox 5 with the objective of getting the patches which had missed
Firefox 4 because of strict approval requirements into the tree. This
was successful, and all of those patches got landed, except for ones
which had a very good reason not to land.
Then, the cedar branch also got used by other people for reasons including:
* No sheriff being around for some people in their timezones, so they
landed on cedar hoping that I merge their change into mozilla-central.
As that requirement has been lifted, this reason is no longer valid.
* People (including me) pushing to cedar because they didn't have time
to watch the tree. This effectively off-loaded the tree watching effort
to me and a few other people who watch cedar fairly regularly. This
solution is not scalable, I'm afraid.
* People (including me) pushing checkin-needed patches to cedar. I
mostly did this because I was not sure if they're safe for landing
directly on mozilla-central. This is still a valid use case, but it
takes some effort to keep doing this.
Out of the above use cases, the only one which remains effectively true
for a now (and the foreseeable future) is to land checkin-needed stuff.
Cedar seems to be a nice staging area for those patches, to make sure
that we get less breakage on mozilla-central, which is an advantage to
everybody.
But this takes a lot of effort on my part, and my experience in the past
three weeks is that asking any single person to maintain this
responsibility indefinitely will cause them to burn out (as I have!).
So, if people feel that Cedar is useful to keep around for this purpose,
we need to find a way to off-load this responsibility among other
people. One way of doing so would be to off-load this to the current
sheriff of the day, but I'm not sure if that is viable for people. I'm
also open to other suggestions.
If people do not feel that Cedar is worth keeping around, I've been
thinking to close it down on this Friday. So, if you want it to live,
now is the time to speak up! :-)
Cheers,
Ehsan
Benjamin Smedberg
> If people do not feel that Cedar is worth keeping around, I've been
> thinking to close it down on this Friday. So, if you want it to live,
> now is the time to speak up! :-)
return it to the "free throwaway pool").
I think there might be a use for something like it owned by the sheriff
of the day, or whoever is doing checkin-needed landings at the current
time, as a sort of permanent tryserver ground for checkin-needed stuff
to get into mozilla-central easily. But let's see how those sorts of
pushes are handled now that the tree is open normally, and see what
happens first.
--BDS
Paul Biggar
<benj...@smedbergs.us> wrote:
> I think there might be a use for something like it owned by the sheriff of
> the day, or whoever is doing checkin-needed landings at the current time, as
> a sort of permanent tryserver ground for checkin-needed stuff to get into
> mozilla-central easily.
I think this would be really useful for new contributors. Currently,
it's a really tough situation to land code as a new contributor - you
dont have access to try, or push rights for any real tree, and so you
need to beg someone to help you, which many contributors do not have
the zeal to ask for.
However, I don't think this 100% solves the problem. New contributors
(the authors of the [checkin-needed] patches) can't actually push
themselves. Would they have to ask the sheriff to push for them? If
so, it would seem to make more sense to land directly on m-c.
--
Paul Biggar
Compiler Geek
pbi...@mozilla.com
Ehsan Akhgari
FWIW, checkin-needed patches can also be landed on mozilla-central.
Someone needs to triage that list regularly. That problem is orthogonal
to whether the cedar branch lives on or not...
Cheers,
Ehsan
Chris AtLee
> FWIW, checkin-needed patches can also be landed on mozilla-central.
> Someone needs to triage that list regularly. That problem is orthogonal
> to whether the cedar branch lives on or not...
>
> Cheers,
> Ehsan
Can we change how "checkin-needed" works? Right now it's a keyword on a
bug. I'd like to see it moved to a flag on individual attachments. Then
you can query for exactly which attachments need to be landed, as it's
not always obvious when there are multiple attachments on a bug.
Cheers,
Chris
Ehsan Akhgari
That is a good idea, but I think the status whiteboard can be used for
this purpose today. And if it's not obvious from the bug, a quick
question from the owner of the bug in a comment (or on IRC) quickly
resolves this issue.
But that's not going to solve anything if the checkin-needed flags are
ignored. It all boils down to this. The list needs to be triaged by
multiple people. And multiple people should assume the responsibility
of landing the patches. It's not a fun job in general, so I understand
why most people wouldn't like to do it. And you're bound to make
embarrassing mistakes [1] which will only make you feel bad (or on a bad
day, get yelled at!). :/
Ehsan
John O'Duinn
Ehsan: thanks (again!) for all the help clearing the backlog after
FF4.0. Other comments below.
On 4/12/11 3:22 PM, Ehsan Akhgari wrote:
> (Follow-ups to dev.planning, please).
>
> tl;dr: I can't maintain cedar forever alone, we need to figure out what
> we want to do with it.
>
> I started the cedar branch at the beginning of the development period
> for Firefox 5 with the objective of getting the patches which had missed
> Firefox 4 because of strict approval requirements into the tree. This
> was successful, and all of those patches got landed, except for ones
> which had a very good reason not to land.
>
> Then, the cedar branch also got used by other people for reasons including:
>
> * No sheriff being around for some people in their timezones, so they
> landed on cedar hoping that I merge their change into mozilla-central.
> As that requirement has been lifted, this reason is no longer valid.
Agreed.
> * People (including me) pushing to cedar because they didn't have time
> to watch the tree. This effectively off-loaded the tree watching effort
> to me and a few other people who watch cedar fairly regularly. This
> solution is not scalable, I'm afraid.
I totally agree it is not scalable having one person watch the tree
after multiple other people land patches (whether its on m-c or cedar).
This feels true for any branch, so unless I'm missing something, this
feels orthogonal to the question of keep cedar in use.
> * People (including me) pushing checkin-needed patches to cedar. I
> mostly did this because I was not sure if they're safe for landing
> directly on mozilla-central. This is still a valid use case, but it
> takes some effort to keep doing this.
>
> Out of the above use cases, the only one which remains effectively true
> for a now (and the foreseeable future) is to land checkin-needed stuff.
> Cedar seems to be a nice staging area for those patches, to make sure
> that we get less breakage on mozilla-central, which is an advantage to
> everybody.
Refreshing your local repo-with-patch to tip of mozilla-central, and
then pushing to TryServer is another good way to do this.
> But this takes a lot of effort on my part, and my experience in the past
> three weeks is that asking any single person to maintain this
> responsibility indefinitely will cause them to burn out (as I have!).
>
> So, if people feel that Cedar is useful to keep around for this purpose,
> we need to find a way to off-load this responsibility among other
> people. One way of doing so would be to off-load this to the current
> sheriff of the day, but I'm not sure if that is viable for people. I'm
> also open to other suggestions.
>
> If people do not feel that Cedar is worth keeping around, I've been
> thinking to close it down on this Friday. So, if you want it to live,
> now is the time to speak up! :-)
As the backlog of patches seems cleared, I also think Cedar has lived
its useful life, and is now done.
However, if anyone thinks Cedar should continue to be used for landings
like this, please chime in, and also provide suggestions on how you want
to moderate/own this branch after Friday.
> Cheers,
> Ehsan
Thanks again, Ehsan!
tc
John.
Mounir Lamouri
> * People (including me) pushing checkin-needed patches to cedar. I
> mostly did this because I was not sure if they're safe for landing
> directly on mozilla-central. This is still a valid use case, but it
> takes some effort to keep doing this.
I really like the idea of having an easy way to push checkin-needed
patches to a repo that has tests enabled. Though, what kind of level
access would be required to push there?
I would be glad to help maintaining cedar with you if the goal is to
have checkin-needed patches pushed there.
--
Mounir
Christian Legnitto
On Apr 12, 2011, at 7:57 PM, Ehsan Akhgari wrote:
> On 11-04-12 10:04 PM, Chris AtLee wrote:
> That is a good idea, but I think the status whiteboard can be used for this purpose today. And if it's not obvious from the bug, a quick question from the owner of the bug in a comment (or on IRC) quickly resolves this issue.
Status whiteboard is bad bad bad bad for structured project stuff. We can't currently query in and out historical rates for a string/"tag" entering/exiting the whiteboard. If we are structured enough to have a standard policy it should be a keyword.
I could not get the in and out rates for soft and hard blockers over Firefox 4 because we tracked them in the whiteboard. Just say no (and make a keyword!).
There is a bug in bugzilla tracking this, but it isn't even fixed in 4.2 so.....
Christian
Chris AtLee
> On 11-04-12 10:04 PM, Chris AtLee wrote:
>> On 12/04/11 09:59 PM, Ehsan Akhgari wrote:
>>> FWIW, checkin-needed patches can also be landed on mozilla-central.
>>> Someone needs to triage that list regularly. That problem is orthogonal
>>> to whether the cedar branch lives on or not...
>>>
>>> Cheers,
>>> Ehsan
>>
>> Can we change how "checkin-needed" works? Right now it's a keyword on a
>> bug. I'd like to see it moved to a flag on individual attachments. Then
>> you can query for exactly which attachments need to be landed, as it's
>> not always obvious when there are multiple attachments on a bug.
>
> That is a good idea, but I think the status whiteboard can be used for
> this purpose today. And if it's not obvious from the bug, a quick
> question from the owner of the bug in a comment (or on IRC) quickly
> resolves this issue.
My thought was that moving the checkin-needed to the attachment removes
the ambiguity over which patch needed landing, and would facilitate
writing tools to assist with triage/landing.
I wanted to write a little app that finds checkin-needed patches,
downloads and lands them on a local repo, then lets you review the
results before pushing. I guess that's still possible with the existing
keyword...
Ehsan Akhgari
> On 12/04/11 10:57 PM, Ehsan Akhgari wrote:
>> On 11-04-12 10:04 PM, Chris AtLee wrote:
>>> On 12/04/11 09:59 PM, Ehsan Akhgari wrote:
>>>> FWIW, checkin-needed patches can also be landed on mozilla-central.
>>>> Someone needs to triage that list regularly. That problem is orthogonal
>>>> to whether the cedar branch lives on or not...
>>>>
>>>> Cheers,
>>>> Ehsan
>>>
>>> Can we change how "checkin-needed" works? Right now it's a keyword on a
>>> bug. I'd like to see it moved to a flag on individual attachments. Then
>>> you can query for exactly which attachments need to be landed, as it's
>>> not always obvious when there are multiple attachments on a bug.
>>
>> That is a good idea, but I think the status whiteboard can be used for
>> this purpose today. And if it's not obvious from the bug, a quick
>> question from the owner of the bug in a comment (or on IRC) quickly
>> resolves this issue.
>
> My thought was that moving the checkin-needed to the attachment removes
> the ambiguity over which patch needed landing, and would facilitate
> writing tools to assist with triage/landing.
That sounds like a good idea. I'm guessing you're talking about a flag
similar to the one used by releng, right?
But how are we planning to make the attachment flag and the
checkin-needed keyword mutually exclusive? Because if we don't, we need
to triage two lists (read: more pain).
Also, I guess it needs to be enabled for Firefox, Toolkit and Core.
Other projects can decide whether they want this on their own.
It should also be reflected in the patch submission documentations.
> I wanted to write a little app that finds checkin-needed patches,
> downloads and lands them on a local repo, then lets you review the
> results before pushing. I guess that's still possible with the existing
> keyword...
There is already such an app. It's called qimportbz. It has a lot of
bugs, but I've heard that timeless is working on fixing them.
Cheers,
Ehsan
Ehsan Akhgari
> On 04/12/2011 03:22 PM, Ehsan Akhgari wrote:
>> * People (including me) pushing checkin-needed patches to cedar. I
>> mostly did this because I was not sure if they're safe for landing
>> directly on mozilla-central. This is still a valid use case, but it
>> takes some effort to keep doing this.
>
> I really like the idea of having an easy way to push checkin-needed
> patches to a repo that has tests enabled. Though, what kind of level
> access would be required to push there?
Level 1, I think.
> I would be glad to help maintaining cedar with you if the goal is to
> have checkin-needed patches pushed there.
Do you want to give that a try for a week to make sure that is really
want you want to do in the long term? :-)
Cheers,
Ehsan
Steve Fink
> On 11-04-13 2:54 AM, Mounir Lamouri wrote:
>> On 04/12/2011 03:22 PM, Ehsan Akhgari wrote:
>>> * People (including me) pushing checkin-needed patches to cedar. I
>>> mostly did this because I was not sure if they're safe for landing
>>> directly on mozilla-central. This is still a valid use case, but it
>>> takes some effort to keep doing this.
>>
>> I really like the idea of having an easy way to push checkin-needed
>> patches to a repo that has tests enabled. Though, what kind of level
>> access would be required to push there?
>
> Level 1, I think.
Huh? I would expect the level of access to be the same as whatever repo
they're going to get merged into. Whoever does the merge should not be
expected to do additional checking to make up the difference between
access levels.
Paul Biggar
>>> I really like the idea of having an easy way to push checkin-needed
>>> patches to a repo that has tests enabled. Though, what kind of level
>>> access would be required to push there?
>>
>> Level 1, I think.
>
> Huh? I would expect the level of access to be the same as whatever repo
> they're going to get merged into. Whoever does the merge should not be
> expected to do additional checking to make up the difference between access
> levels.
If they had the right level of access, why would they be using [checkin-needed]?
Ehsan Akhgari
> On 04/13/2011 11:51 AM, Ehsan Akhgari wrote:
>> On 11-04-13 2:54 AM, Mounir Lamouri wrote:
>>> On 04/12/2011 03:22 PM, Ehsan Akhgari wrote:
>>>> * People (including me) pushing checkin-needed patches to cedar. I
>>>> mostly did this because I was not sure if they're safe for landing
>>>> directly on mozilla-central. This is still a valid use case, but it
>>>> takes some effort to keep doing this.
>>>
>>> patches to a repo that has tests enabled. Though, what kind of level
>>> access would be required to push there?
>>
>> Level 1, I think.
>
> Huh? I would expect the level of access to be the same as whatever repo
> they're going to get merged into. Whoever does the merge should not be
> expected to do additional checking to make up the difference between
> access levels.
Oh, well, I got the ordering wrong. I thought Level 1 is the highest,
but it seems that Level 3 is. That's what I meant.
Ehsan
Steve Fink
> On Wed, Apr 13, 2011 at 12:05 PM, Steve Fink<sf...@mozilla.com> wrote:
>>>> patches to a repo that has tests enabled. Though, what kind of level
>>>> access would be required to push there?
>>> Level 1, I think.
>> Huh? I would expect the level of access to be the same as whatever repo
>> they're going to get merged into. Whoever does the merge should not be
>> expected to do additional checking to make up the difference between access
>> levels.
The person *setting* [checkin-needed] does not need the right level of
access. The nice person *pushing* the [checkin-needed] patches needs the
right level of access, as does the even nicer person merging that repo
into m-c.
Steve Fink
> On 11-04-13 3:05 PM, Steve Fink wrote:
>> On 04/13/2011 11:51 AM, Ehsan Akhgari wrote:
>>> On 11-04-13 2:54 AM, Mounir Lamouri wrote:
>>>> On 04/12/2011 03:22 PM, Ehsan Akhgari wrote:
>>>>> * People (including me) pushing checkin-needed patches to cedar. I
>>>>> mostly did this because I was not sure if they're safe for landing
>>>>> directly on mozilla-central. This is still a valid use case, but it
>>>>> takes some effort to keep doing this.
>>>>
>>>> patches to a repo that has tests enabled. Though, what kind of level
>>>> access would be required to push there?
>>>
>>> Level 1, I think.
>>
>> Huh? I would expect the level of access to be the same as whatever repo
>> they're going to get merged into. Whoever does the merge should not be
>> expected to do additional checking to make up the difference between
>> access levels.
>
> but it seems that Level 3 is. That's what I meant.
Ah, ok, that explains it.
Mounir Lamouri
>> have checkin-needed patches pushed there.
>
> Do you want to give that a try for a week to make sure that is really
> want you want to do in the long term? :-)
I can try to do that next week.
--
Mounir
Ehsan Akhgari
Sounds great, thanks!
Ehsan
Justin Wood (Callek)
> Also, I guess it needs to be enabled for Firefox, Toolkit and Core.
> Other projects can decide whether they want this on their own.
If you do it for those products, please do it for |SeaMonkey| as well,
I'll have to consult if we want it for |MailNews Core| and |Thunderbird|
but I suspect that answer will be "yes please" too.
--
~Justin Wood (Callek)
timeless
> If they had the right level of access, why would they be using [checkin-needed]?
because sitting around playing with tbpl for dozens of hours isn't a
good use of time.