Branched for release

Branched for release

[Richard Purdie]

Just a heads up for people that we've branched for release and that
jethro branches are now available. Bitbake branched as 1.28, I decided
to save bitbake 2.0 for another occasion.

These branches are going to track master for a while yet as we stabilise
the release.

Cheers,

Richard

Re: Branched for release

[Khem Raj]

On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Just a heads up for people that we've branched for release and that
> jethro branches are now available. Bitbake branched as 1.28, I decided
> to save bitbake 2.0 for another occasion.

what would be the occasion ?
this time lets branch consistently. Across different repositories
please.  I would also suggest to not use codenames in branches
but rather the numbered release. If we want to use codenames for
branches then lets drop the numbered release names.

>
> These branches are going to track master for a while yet as we stabilise
> the release.
>
> Cheers,
>
> Richard
>
>
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: Branched for release

[Otavio Salvador]

On Thu, Oct 1, 2015 at 11:28 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> Just a heads up for people that we've branched for release and that
>> jethro branches are now available. Bitbake branched as 1.28, I decided
>> to save bitbake 2.0 for another occasion.
>
> what would be the occasion ?
> this time lets branch consistently. Across different repositories
> please.  I would also suggest to not use codenames in branches
> but rather the numbered release. If we want to use codenames for
> branches then lets drop the numbered release names.

I agree.

The mix between codenames and version numbers cause a lot of confusion
for outsiders. We, involved with the project development can handle it
(even though sometimes I ask myself if one codename is older or newer
than another) but for outsiders it is deadly confusing.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Branched for release

[Carlos Alberto Lopez Perez]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

On 01/10/15 16:28, Khem Raj wrote:
> I would also suggest to not use codenames in branches
> but rather the numbered release. If we want to use codenames for
> branches then lets drop the numbered release names.
> 

I suggest using both (codename+release_number).

Ex: jethro-2.0 or 2.0-jethro

(probably the later one is better as it can be sorted by release number
easily)

That way everyone has clear which release number and which codename is,
without having to fire a browser to
https://wiki.yoctoproject.org/wiki/Releases



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: Branched for release

[Khem Raj]

On Thu, Oct 1, 2015 at 8:03 AM, Carlos Alberto Lopez Perez
<clopez@igalia.com> wrote:
> On 01/10/15 16:28, Khem Raj wrote:
>> I would also suggest to not use codenames in branches
>> but rather the numbered release. If we want to use codenames for
>> branches then lets drop the numbered release names.
>>
>
> I suggest using both (codename+release_number).
>

It would be good to have simple and revealing names like release-X.Y
or branch-point-X.Y for tags etc.
And this would also then benefit rest of projects under YP umbrella if
they were to use same release numbering.
OE is a bit unique then other distribution frameworks in regards that
the user has to interact with sources since
its source based unlike other distro's like fedora and debian-like
which are binary feed based for most of users
and a small subset deals with the build metadata repositories. So it
would help the community at large if there
was simple naming conventions.

> Ex: jethro-2.0 or 2.0-jethro
>
> (probably the later one is better as it can be sorted by release number
> easily)
>
> That way everyone has clear which release number and which codename is,
> without having to fire a browser to
> https://wiki.yoctoproject.org/wiki/Releases
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: Branched for release

[Richard Purdie]

On Thu, 2015-10-01 at 07:28 -0700, Khem Raj wrote:
> On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > Just a heads up for people that we've branched for release and that
> > jethro branches are now available. Bitbake branched as 1.28, I decided
> > to save bitbake 2.0 for another occasion.
> 
> what would be the occasion ?

Memory resident Bitbake? Toaster developments? Logging improvements? New
shell commands?

> this time lets branch consistently. Across different repositories
> please.

Bitbake is the only repo which doesn't use the branch codename. I did
write at length about how version numbers as branches would actually
cause much more pain than any problem they solve, bitbake is one of the
few exceptions to that given its a tool, not metadata and has a more
consistent history where the version number means something specific and
is actively used.

>   I would also suggest to not use codenames in branches
> but rather the numbered release. If we want to use codenames for
> branches then lets drop the numbered release names.

The number does have some uses, its really not that simple.

If we want to discuss this all again, so be it, but on the eve of
release really isn't the time to start it all again.

Cheers,

Richard

Re: Branched for release

[Richard Purdie]

On Thu, 2015-10-01 at 11:41 -0300, Otavio Salvador wrote:
> I agree.
> 
> The mix between codenames and version numbers cause a lot of confusion
> for outsiders. We, involved with the project development can handle it
> (even though sometimes I ask myself if one codename is older or newer
> than another) but for outsiders it is deadly confusing.

As I've just replied to Khem, I posted a fairly comprehensive look at
all the possible options quite a while back, the last time people
complained. Basically, we can't win. We have slowly killed off all the
numbers that didn't have a purpose so we have one naming scheme and one
number that corresponds to it.

The only real exception is bitbake, which as tool with its own
release/versions, makes sense.

I'd also highlight that now is not the time to start changing the
release process.

Cheers,

Richard

Re: Branched for release

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]


> On Oct 1, 2015, at 8:37 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Thu, 2015-10-01 at 07:28 -0700, Khem Raj wrote:
>> On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> Just a heads up for people that we've branched for release and that
>>> jethro branches are now available. Bitbake branched as 1.28, I decided
>>> to save bitbake 2.0 for another occasion.
>> 
>> what would be the occasion ?
> 
> Memory resident Bitbake? Toaster developments? Logging improvements? New
> shell commands?
> 

bitbake is tied ot OE metadata, even though its a separate repository, it can be viewed
as any other metadata layer.Moreover I don’t know if there are any other projects besides OE using
it. All above look good features but not clear whats there relation to bumping major release
number. Do they make 1.9 incompatible in some different ways than that we don’t do between 1.x releases ?

>> this time lets branch consistently. Across different repositories
>> please.
> 
> Bitbake is the only repo which doesn't use the branch codename. I did
> write at length about how version numbers as branches would actually
> cause much more pain than any problem they solve, bitbake is one of the
> few exceptions to that given its a tool, not metadata and has a more
> consistent history where the version number means something specific and
> is actively used.
> 
>>  I would also suggest to not use codenames in branches
>> but rather the numbered release. If we want to use codenames for
>> branches then lets drop the numbered release names.
> 
> The number does have some uses, its really not that simple.
> 

They do tell me the chronology of releases I get that but then I don’t understand
why can’t be use it in name for branching then, why does it have to be no relation
between branch and release names ?

I am not sure if you are aware enough of the confusion it causes to new users, not all distros
use combo layer like tools to fudge the layer identities and create a new repositories where this can be less
of the problem since the new repository could have its own versioning scheme.


> If we want to discuss this all again, so be it, but on the eve of
> release really isn't the time to start it all again.

so when is the right time ? Do we have long enough pre-notice about when we the branching is going to happen?

> 
> Cheers,
> 
> Richard
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: Branched for release

[Richard Purdie]

On Thu, 2015-10-01 at 10:24 -0700, Khem Raj wrote:
> > If we want to discuss this all again, so be it, but on the eve of
> > release really isn't the time to start it all again.
> 
> so when is the right time ? Do we have long enough pre-notice about
> when we the branching is going to happen?

We release approximately in April and October with a six month cadence. 

After the complaints about communication, there have been weekly status
updates and the release dates were also *clearly* shown in there for
when the release was planned. Incidentally, if those aren't useful,
Stephen and I can stop doing them.

Its not unreasonable to assume the branch for release happens sometime
before the first rc build of the release.

Cheers,

Richard

Re: Branched for release

[Khem Raj]

On Thu, Oct 1, 2015 at 1:25 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> so when is the right time ? Do we have long enough pre-notice about
>> when we the branching is going to happen?
>
> We release approximately in April and October with a six month cadence.
>
> After the complaints about communication, there have been weekly status
> updates and the release dates were also *clearly* shown in there for
> when the release was planned. Incidentally, if those aren't useful,
> Stephen and I can stop doing them.
>
> Its not unreasonable to assume the branch for release happens sometime
> before the first rc build of the release.

treat this as discussion for next release, since enough water has
passed to make it for this one. I will open a bug in yocto tracker as
well as a  reminder

Re: Branched for release

[Otavio Salvador]

On Thu, Oct 1, 2015 at 5:25 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2015-10-01 at 10:24 -0700, Khem Raj wrote:
>> > If we want to discuss this all again, so be it, but on the eve of
>> > release really isn't the time to start it all again.
>>
>> so when is the right time ? Do we have long enough pre-notice about
>> when we the branching is going to happen?
>
> We release approximately in April and October with a six month cadence.
>
> After the complaints about communication, there have been weekly status
> updates and the release dates were also *clearly* shown in there for
> when the release was planned. Incidentally, if those aren't useful,
> Stephen and I can stop doing them.
>
> Its not unreasonable to assume the branch for release happens sometime
> before the first rc build of the release.

I think what Khem means is that any time is time to discuss the
release process as this is a community driven project and we must to
be open for feedback and revisit our previous concepts.

I agree with Khem concerns here and I also believe we should rethink
the versioning / branching schema.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Branched for release

[Richard Purdie]

On Thu, 2015-10-01 at 17:30 -0300, Otavio Salvador wrote:
> I think what Khem means is that any time is time to discuss the
> release process as this is a community driven project and we must to
> be open for feedback and revisit our previous concepts.

There is a time and a place for such discussions. I think its clear that
right now, I'm personally finding the situation we're in rather
stressful and even getting the release into a shape where it can ship is
proving difficult.

The last thing I need right now is to go through this discussion again.
Particularly when people have not gone and read the things I wrote up
last time this was discussed. I could ask why not, the answer is
probably because its easier just to ask questions and be unhappy with
what we have.

I appreciate that what we have today does cause some issues. I also
realised a while ago that regardless of what solution we pick, there are
people who are not going to like it. I've talked about that in previous
mailing list posts to try and explain why we end up where we are today.
I also don't believe anything has materially changed since we last
discussed this, some people are just still unhappy. Some people will be
unhappy regardless.

I'm actually at a pretty low point with OE and Yocto in general. It eats
up a huge amount of my time, both work and personally and I have started
wondering what I actually get out of it other than a shortened life
expectancy. On the most part I see a lot of complaints about things and
continual questioning of "why we do X and wouldn't Y be better". I do my
best to deal with this patiently and each time try and explain why and
then re-evaluate if a change makes sense or not. When the same things
repeat time and again, my patience can wear thin though.

Now, I do realise that there probably are some happy users out there and
that happier users tend to be quieter than the unhappy ones, at least I
certainly hope so. As such, I tend to see the worst side of the projects
all the time. Equally, it can get to you after a while.

So, yes, I do believe there is a time and place for discussions and not
everything should be questioned and discussed at any time. That doesn't
mean its not a community driven project.

Anyhow, I can't stop any discussion, however my point is I'd much prefer
to spend my time trying to sort out the release. If others feel
differently, I will indeed have to spend more time on this instead. I do
also believe it is too late to change things for this release[1].

[1] Since I will no doubt get asked to explain that, the consequences
are quite significant when you consider bugzilla version fields,
autobuilder scripts, release scripts, my own branching scripts and so
on. The things I haven't thought of worry me even more. Yes, we can in
theory change anything and we could change this, but its probably a week
of work shaking out just those changes. Do I want to do that now? No, I
don't. For example I'm attending ELC-E next week. Do we want me talking
to people or sitting in a corner trying to un-break such a change?

Cheers,

Richard

Re: Branched for release

[Khem Raj]

On Thu, Oct 1, 2015 at 1:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, Oct 1, 2015 at 1:25 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>> so when is the right time ? Do we have long enough pre-notice about
>>> when we the branching is going to happen?
>>
>> We release approximately in April and October with a six month cadence.
>>
>> After the complaints about communication, there have been weekly status
>> updates and the release dates were also *clearly* shown in there for
>> when the release was planned. Incidentally, if those aren't useful,
>> Stephen and I can stop doing them.
>>
>> Its not unreasonable to assume the branch for release happens sometime
>> before the first rc build of the release.
>
> treat this as discussion for next release, since enough water has
> passed to make it for this one. I will open a bug in yocto tracker as
> well as a  reminder

I have opened a tracker for 2.1 in bugzilla for this
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8432
everyone please feel free to record your inputs to this ticket.

Re: Branched for release

[Khem Raj]

On Thu, Oct 1, 2015 at 2:16 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2015-10-01 at 17:30 -0300, Otavio Salvador wrote:
>> I think what Khem means is that any time is time to discuss the
>> release process as this is a community driven project and we must to
>> be open for feedback and revisit our previous concepts.
>
> There is a time and a place for such discussions. I think its clear that
> right now, I'm personally finding the situation we're in rather
> stressful and even getting the release into a shape where it can ship is
> proving difficult.
>
> The last thing I need right now is to go through this discussion again.
> Particularly when people have not gone and read the things I wrote up
> last time this was discussed. I could ask why not, the answer is
> probably because its easier just to ask questions and be unhappy with
> what we have.
>
> I appreciate that what we have today does cause some issues. I also
> realised a while ago that regardless of what solution we pick, there are
> people who are not going to like it. I've talked about that in previous
> mailing list posts to try and explain why we end up where we are today.
> I also don't believe anything has materially changed since we last
> discussed this, some people are just still unhappy. Some people will be
> unhappy regardless.

>
> I'm actually at a pretty low point with OE and Yocto in general. It eats
> up a huge amount of my time, both work and personally and I have started
> wondering what I actually get out of it other than a shortened life
> expectancy. On the most part I see a lot of complaints about things and
> continual questioning of "why we do X and wouldn't Y be better". I do my
> best to deal with this patiently and each time try and explain why and
> then re-evaluate if a change makes sense or not. When the same things
> repeat time and again, my patience can wear thin though.

believe me you are doing a fine job :) infact I recognise that
maintainership is a thankless job.

>
> Now, I do realise that there probably are some happy users out there and
> that happier users tend to be quieter than the unhappy ones, at least I
> certainly hope so. As such, I tend to see the worst side of the projects
> all the time. Equally, it can get to you after a while.
>

No silence does not mean happiness and similarity bringing up issues
does not mean unhappiness, On the contrary It is that I am being
caring enough to help projects adoption in the areas where people
havent heard the name of OE, so its a different perspective and
vouch for the issues that gets a headwind in adoption.


> So, yes, I do believe there is a time and place for discussions and not
> everything should be questioned and discussed at any time. That doesn't
> mean its not a community driven project.
>
> Anyhow, I can't stop any discussion, however my point is I'd much prefer
> to spend my time trying to sort out the release. If others feel
> differently, I will indeed have to spend more time on this instead. I do
> also believe it is too late to change things for this release[1].
>
> [1] Since I will no doubt get asked to explain that, the consequences
> are quite significant when you consider bugzilla version fields,
> autobuilder scripts, release scripts, my own branching scripts and so
> on. The things I haven't thought of worry me even more. Yes, we can in
> theory change anything and we could change this, but its probably a week
> of work shaking out just those changes. Do I want to do that now? No, I
> don't. For example I'm attending ELC-E next week. Do we want me talking
> to people or sitting in a corner trying to un-break such a change?
>

I think you are right about timing. But on and off this discussion has
come up and incidentally its always during release
I guess because we all try to consume the changes and it comes to fore
anyhow I have opened a tracker bug to follow it up. Let everyone
record the
inputs there, so it can be then considered for next release.

> Cheers,
>
> Richard
>
>